[FIX] Fix & Review Bind9

[lasley]

Moving conversation from #175 to here:

Annnnd I'd like to say debug bind, but no it's not working yet... It's starting to be a problem and a priority I need help, I don't understand were the problem is coming (even an nslookup from inside the bind container is not working). The cause seems to be the move to alpine.
I need a bind guru to look at it, and if possible review the entire configuration because I'm pretty sure it's insecure, I am really bad with DNS.

@t3ddftw - you use bind much? I can't recall the last time I've used it TBH

Notes:

Init script does not work (although I don't think related)

bash-4.3# /etc/init.d/named status
bash: /etc/init.d/named: /sbin/openrc-run: bad interpreter: No such file or directory

Installed OpenRC, try again

bash-4.3# /etc/init.d/named status
 * You are attempting to run an openrc service on a
 * system which openrc did not boot.
 * You may be inside a chroot or you may have used
 * another initialization system to boot this system.
 * In this situation, you will get unpredictable results!
 * If you really want to do this, issue the following command:
 * touch /run/openrc/softlevel

[lasley]

Looking at it from a high level, we are missing DNSSEC responses

[YannickB]

For the record, I wasn't completely sure we should continue to use bind, I had to check if there wasn't another software for this purpose (maybe one with a web interface for example for easier management).

I wanted to continue with bind for now because of lack of time and we already had something working, but with the error maybe it's time to check.

And anyway, I wanted someone to check the DNS config because as I said I was worry it was insecure.

[lasley]

We need authoritative and not secondary right? What about something like Erl-DNS, which allows us to store the zones in Postgres?

Or maybe PowerDNS, which maybe is a bit better. It uses SQLite for its zones.

[YannickB]

Reading https://blog.dnsimple.com/2015/02/top-dns-servers/, yeah Erl-DNS and PowerDNS got my attention.

I'm not sure about the need of postgres, but we may need it later when we scale. At the very least, even if I don't suggest using postgres right now it's probably more secure to go with a software which can use it.

One strong argument against bind for me, which was mentioned for PowerDNS in the article : CLI. I'm so pissed off with the file-based configuration of bind right now.
And with the daemon reload which last year worked only half of the time, which forced me to restart the bind container almost each time... I almost felt like half of the oneclick deployment was spent in bind restart.
I feel like I suddenly just got the motivation to oust bind...

So, I guess it's between erl-dns and powerdns now. What do you think ?

[lasley]

Yeah I've honestly never had luck with bind. File based config is totally 1990s IMO, although I bet @t3ddftw would argue against that for days. That type of config keeps those crazy Ops guys like him in business 😛

So regarding the other two servers. Both of them are developed on Github, which is a 👍 from me in terms of ecosystem. I've messed around with both in lab environment, and they're about equal in terms of pros/cons on each. They're also about the same in terms of modularity.

I think I kind of lean towards Erl-DNS, but here are some observations I remember. This presentation by the founder of DNSSimple is a good skim too.

PowerDNS

More mature and more active project.

It supports basically any database backend, which is kind of neat in terms of versatility.

Has an excellent Recursor.

Erl-DNS

Even though I don't much like the language, the fact that this is built in Erlang is a huge plus. Erlang was designed from the ground up specifically for use in core network operations such as this. I would lay a bet on it being more stable as well, but this is only inferred by Erlangs concept crash handling.

Win for runtime metrics/stats goes to Erl-DNS. It has Folsom for the metrics & an HTTP api.

I may have missed it, but I do not believe that Erl-DNS offers a recursor. This means it can only be an authoritative server, which kind of sucks.

[YannickB]

Ok. From what I see I'd tend to PowerDNS, I always prefer more active projects.

Regarding backend, am I right to assume we can either use bind backend (!) or postgresql ? If no other realistic choice of course we'd go to postgres.

[lasley]

PowerDNS has releases on their Github too, vs I'm not sure where the Erl-DNS releases are.

PowerDNS backend grid is here - https://doc.powerdns.com/md/authoritative/#backend-capabilities

Take a look at the concept of a Superslave too, quite hot.

[pasgou]

When I read that I think : why not use API from a provider which sell the DN?
For example, ovh and gandi give open API to buy and configure dns on there servers, which will be more secure and redundant ever than a private one. In this case, we have to store API keys in the configuration info for thoses services which even could permit to buy and configure new nodes for clouder swarm with the same API keys.

I know you want to be provider agnostic but there is two contexts where i don't understand where is the pragmatism :

• dns : we need to buy en to a provider who offend give the possibility via API to manage zones directly on its servers. As a French company, I think immediately of OVH or GANDI.net.
• servers : idem. With ovh we can provision public cloud or other servers via API and send initialisations scripts immediately to install supervision, firewall and docker swarm tools

Or I am completely wrong?

[YannickB]

Hello @pasgou

Yes as I explained in #185 , we use libcloud to be able to connect to API provider.

• We still want to have an internal DNS, mainly so student or anyone without real money can test Clouder and deploy it without having to pay on external services. Also, the oneclick installation use internal DNS to have a instant ready to use infrastructure, and then you can replace the DNS service by libcloud.

• But we agree that for real use production, external services are mandatory, that's why we integrated libcloud to manage API connection to all major cloud providers.

[lasley]

Even outside of a student - most offices still have internal DNS. I will most certainly be using both the internal and external forwarders in production.

[pasgou]

I need so information on how to manage the DNS : how to say to provider that the DNS is ou DNS and not the one of the provider.

@YannickB it could be interesting to meet us at Paris or Nantes.

[YannickB]

When you deploy the DNS container, you either deploy a bind (powerdns in the future) container, or a dummy container which contain libcloud credentials.

Then, when you deploy the link between base and this container, it will either configure bind or send the request to the external provider.

@pasgou Sure, let me know when you come at Paris we need to meet. I have some people to see at Nantes, so maybe I'll consider take the road but not this month.