Skip to content
This repository has been archived by the owner on May 13, 2024. It is now read-only.

DNSSEC not enabled #25

Open
h3ndrk opened this issue Aug 16, 2019 · 6 comments
Open

DNSSEC not enabled #25

h3ndrk opened this issue Aug 16, 2019 · 6 comments

Comments

@h3ndrk
Copy link

h3ndrk commented Aug 16, 2019

This is related to #18, but I have a different issue:

I haven't modified the pdns.conf (so it has #gmysql-dnssec=no in it, which is commented out). Then I pass the cli flag --gmysql-dnssec=yes to the container. The following output is ps afx from inside the container:

    1 root       0:00 {entrypoint.sh} /bin/sh /entrypoint.sh --dnsupdate=yes --allow-dnsupdate-from=192.168.0.0/16 10.96.0.0/12 10.1.0.0/24 --gmysql-dnssec=yes --log-dns-details=yes --log-dns-queries=yes --loglevel=6 --query-logging=yes
   21 root       0:00 pdns_server --dnsupdate=yes --allow-dnsupdate-from=192.168.0.0/16 10.96.0.0/12 10.1.0.0/24 --gmysql-dnssec=yes --log-dns-details=yes --log-dns-queries=yes --loglevel=6 --query-logging=yes
   23 pdns       0:00 pdns_server-instance --dnsupdate=yes --allow-dnsupdate-from=192.168.0.0/16 10.96.0.0/12 10.1.0.0/24 --gmysql-dnssec=yes --log-dns-details=yes --log-dns-queries=yes --loglevel=6 --query-logging=yes

From inside the container I'm using pdnsutil to enable DNSSEC for my zone which does not work:

/ # pdnsutil secure-zone example.com
Securing zone with default key size
Adding CSK (257) with algorithm ecdsa256
No backend was able to secure 'example.com', most likely because no DNSSEC
capable backends are loaded, or because the backends have DNSSEC disabled.
For the Generic SQL backends, set the 'gsqlite3-dnssec', 'gmysql-dnssec' or
'gpgsql-dnssec' flag. Also make sure the schema has been updated for DNSSEC!

Maybe the last sentence is a hint?

I also ran:

/ # pdnsutil rectify-zone example.com
Adding empty non-terminals for non-DNSSEC zone

Followed by another:

/ # pdnsutil secure-zone example.com
Securing zone with default key size
Adding CSK (257) with algorithm ecdsa256
No backend was able to secure 'example.com', most likely because no DNSSEC
capable backends are loaded, or because the backends have DNSSEC disabled.
For the Generic SQL backends, set the 'gsqlite3-dnssec', 'gmysql-dnssec' or
'gpgsql-dnssec' flag. Also make sure the schema has been updated for DNSSEC!

I'm using psitrax/powerdns:4.1.10.

What is the problem? Do you need more informations?

Thanks in advance!

@h3ndrk
Copy link
Author

h3ndrk commented Aug 22, 2019

Some progress: I've compiled with aggressive logging which shows that GSQLBackend::d_dnssecQueries is false. That should be true because of --gmysql-dnssec=yes.

See https://github.com/PowerDNS/pdns/blob/7c8a702b63619397cd9a8678c5b5c6cb608e6357/pdns/backends/gsql/gsqlbackend.cc#L699-L702

@h3ndrk
Copy link
Author

h3ndrk commented Aug 22, 2019

GSQLBackend::d_dnssecQueries is false because the configuration yields gmysql-dnssec=no by default (because it has #gmysql-dnssec=no in it, which is commented out, but the default is no).

Since I'm using pdnsutil inside the docker container via docker exec the command line arguments of the PowerDNS server are not available to executed commands (they are only using the default configuration). Furthermore pdnsutil does not have convinient options for overwriting such value. It simply uses the configuration at /etc/pdns/pdns.conf which yields no. (As a proof: When setting the value =yes in /etc/pdns/pdns.conf everything works in pdnsutil.)

The only way (I found) to enable DNSSEC for other commands without modifying the configuration /etc/pdns/pdns.conf is to mount a file e.g. /etc/pdns/conf.d/10-gmysql-dnssec.conf with the contents:

gmysql-dnssec=yes

@h3ndrk h3ndrk closed this as completed Aug 22, 2019
@psi-4ward psi-4ward reopened this Aug 27, 2019
@psi-4ward
Copy link
Owner

I think this is not a smooth way. Perhaps we could add some bootstrap-script to add the conf file when some env-vars are set or smth like this?

@h3ndrk
Copy link
Author

h3ndrk commented Aug 27, 2019

It might be possible to translate cli arguments to configuration parameters by removing the ---prefix and then storing that in configuration files. Other commands would see that too. (Does this work for array- or map-arguments? Does this work with arguments with a space in between? This prefix transformation might not be trivial in bash...)

Another way would be to define additional configuration parameters (which is nearly the same as mounting a file). I don't like mixing the two possibilities (or giving the user both possibilities). Instead we should prefer one method.

@psi-4ward
Copy link
Owner

So you mean better to compile with yes flag? What does this mean for backward compat?

@h3ndrk
Copy link
Author

h3ndrk commented Aug 27, 2019

No, I meant it in a more general way:

I think the overall problem is that commands executed inside the container (like pdnsutil) are unable to directly use the cli arguments. To address this I've proposed the transformation approach which would fix it in general (when someone needs another flag in the future we are prepared). But it is also a major and non-trivial change.

Also one could propose a change in the official pdnsutil binary so that it accepts the same cli arguments as the PowerDNS server.

We could also add a custom environment variable to place a configuration file for this particular issue only. Backward compatibility: Since the value is disabled by default and we will optionally enable it via the environment variable this should work most of the time. Problems might arise when we accidentally overwrite a configuration file.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants