The strange thing is that I have with my basic named configuration the same problem with dbs.si. The “secure DNS” servers of my provider do resolve it.
“dig @195.47.224.12 dbs.si” does not resolve.
nslookup - 195.47.224.12 /search dbs.si does resolve, but with comm err.
Who to blame???
This is beyond my limited knowledge.
However, https://dnssec-analyzer.verisignlabs.com/dbs.si shows that there are problems with this domain.
For now timeouts are gone when I disabled ipv6 (named.service) not in named.conf
...
/usr/sbin/named -4 -u named -d 8 -f -c /etc/named.conf
...
and disabled dnsec in named.conf
dnssec-validation no;
Not sure if this has some change for running my authoritative DNS, as I don’t have and IPv6 IP defined for my domains, nor I use IPv6 in my local nets. It would be good to be able to use dnssec-validation. I’ve updated named.root.key but no change I still get an error.
It could have been root-keys. I"ve noticed that my old file had
managed-keys {
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
.....
QxA+Uk1ihz0=";
....
but newer named.root.key
trust-anchors {
. initial-ds 20326 8 2 "E06D4.......3457104237C7F8EC8D";
};
have to play with it more, or rather study ISC documentation
btw that dbs.si is a site of the bank, so it should have proper DNS response. I’m not sure if I get error due to dnssec off or their wrong DNS response.
dbs.si does not reveal it’s adres with “dig +trace”. dbs.si is also silent if you consult it’s own authorative nameserver “ns1.dbs.si” with dig. I found that “dig +nocookie” works. Translated to “send-cookie false” in /etc/named.conf, dbs.si has now an address on 127.0.0.1. I must admit I do not know what I’m exactly doing, I’ve to read the dnssec stuff in bind manual, but may be it’s a hint in the right direction.
Sometimes using IPv6 may have problems when version 6 is not in use nor properly routed. I suspect that switching to IPv4 only may have solved several factors.
A lot to learn about new DNS features. Anyhow, partly you’re struggling against badly configured servers, see EDNS Compliance Tester and type dbs.si.
This server causes FORMERR messages.
I do not know yet how to fix this, global “send-cookie false” is not recommended.
Second thing I learned, may be important for external: be sure that both UDP and TCP port 53 are opened in Fedora and router for IPv4 and optionally IPv6. If you use firewalld in Fedora and open DNS service, this should be fine.
Yes it could have been the issue with IPv6 routing. I’ve enabled managed-keys and trust-anchors with bindkeys-file and include directives and it seems that dnssec is also working now.
The only thing is now, that for some reasons when I remove -4 from starting named, some of my servers will start to be unreachable, and I’m yet to find what is the difference in the routing/ip#/named configurations between them
So I’m still not sure if I should have my resolv.conf with
nameserver 127.0.0.53
or
nameserver 127.0.0.1
They are both working, and I kept resolved.service running as it didn’t do and change. But it is true that with 127.0.0.53, more names get resolved ie the problematic dbs.si.
If I understand correctly 127.0.0.53 will query upstream DNS for all queries of the machine and also DHCP clients, but will normally respond to Authority requests on my public IP from the outside, whereas 127.0.0.1 will respond to all internal and all DHCP client queries from my own named.service?
In contrast to my previous message, I’ve both named and systemd-resolved active. If a RedHat employee writes that they are incompatible, I tend to believe it, but it could be improved in mean time. Normal config is having systemd-resolved on providers DNS. I typed “resolvectl dns <outgoing interface> 127.0.0.1” and now named is used to provide data to systemd-resolved. It’s only maintaining a double cache by feeding a caching nameserver from a caching nameserver on the same machine, but as far I can see, they do not interfere.
Since systemd-resolved only binds to 127.0.0.53 in standard config and named to all interfaces, the outside world sees your named server.
At the moment I think it works on my site, even with DNSSEC validation without major changes in the example configs.
So are you saying that keeping nameserver 127.0.0.53 in resolv.conf and named running on all interfaces ie 127.0.0.1; 192.168.x.1; public-ip; will work without interference and named will respond normally to all authority requests from outside world. Thus this is the best solution?
I do not want to say that this is the best solution, but on my system it works. If you want to have normal workstation functionality, with DNS from upstream, as far I can see it works as expected, and outside sees your own nameserver. If you want to use your “named” DNS on the PC running “named”, I would avoid double caching, disable systemd-resolved and put “nameserver 127.0.0.1” in /etc/resolv.conf file in order to avoid needless complexity. But as far I could see even chaining named and systemd-resolved works. Quick test, no production, so surprises always can happen…
The site “dbs.si” can be activated by including
server 195.47.224.8/29 {
send-cookie false;
};
in /etc/named.conf.
The subnet definition includes the both nameservers. I wonder how professional DNS administrators handle those exceptions… If a few % of the nameservers is not able to correctly handle the newest security mechanisms, this would be a though job.
I managed to get my DNS working without timeout issues. I think it was a problem that localhost wasn’t signed. I’ve done following changes in named.conf
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
dnssec-validation auto;
include "/etc/crypto-policies/back-ends/bind.config";
I’ve commented out all key files.
I’ve modified rfc1912.zone file adding last two lines to lochalhost
zone "localhost" IN {
type master;
file "named.localhost";
allow-update { none; };
inline-signing yes;
auto-dnssec maintain;
};
and I don’t get any more messages like:
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
validating ./DNSKEY: no valid signature found (DS)
managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
And I was able to enable IPv6 also when starting named.