DNS lookup fails - since 3.10.7?

This just started happening this morning, suddenly no new DNS lookups are working.

Resetting the box does no good and I’ve even added my ISP’s DNS address to the DNS forwarding list but to no avail.

I’m not sure how I can tell when my box updated itself but this problem has only just started, so the inference is fairly likely.

I can log on via ssh so if there are any diagnostics I can run that way to assist I’ll be happy to do so. Currently I am working around this by adding the ISP’s DNS to resolve.conf on all my boxes, but this has to be reset after every reboot (fortunately my wife hardly ever reboots).

The DNS root KSK rollover happened at 1600 UTC on 11 October.

Probably a resolver problem of Your ISP???

For updates on the status, see the rollover status page. Updates will be sent to the https://mm.icann.org/listinfo/ksk-rollover mailing list. If you are having an emergency with your resolver, please see the information immediately below.

This page has general information about the KSK rollover. If you came here looking how to update to the latest KSK trust anchor, please see https://www.icann.org/dns-resolvers-updating-latest-trust-anchor this page.

I don’t think this is anything to do with my ISP.

My turris omnia is not the main interface to the outside world; when we upgraded to our ISP’s higher speed service, almost 2 years ago, the new cable modem came as part of a hitron router. The hitron is and gives the omnia with the omnia running the internal network on 192,168.1.1.

If I connect any of my systems directly to the hitron then they have no problem with DNS resolution at all, but then they cannot access the rest of the internal network.

If I manually set any system’s /etc/resolv.conf to include as a nameserver then DNS resolution works, but this is not a solution for any of the 3 android tablets in the house.

I have set DNS forwardings in the General Settings tab of the DHCP and DNS page (luci) to but this does not work. I also tried connecting to the omnia via ssh and running dig, which does not try to use, but I don’t know if you would expect it to.

Any more thoughts? Anything I could try to pin the problem down?

To be sure I’d check this over ssh:

root@turris:~# cat /etc/root.keys 
.                       172800  DNSKEY  257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ; Valid: ; KeyTag:19036
.                       172800  DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ; Valid: ; KeyTag:20326

– the main thing to check is that there are two lines with Valid: at the ends, you may also check if the KeyTag: numbers are the same (but those seem unlikely to be wrong if there are two lines).

If this is wrong, a quick recovery should be to just edit the file to the state I posted (it’s not sensitive to details like whitespace). Then /etc/init.d/resolver restart .

Thank you!

The second line of /etc/root.keys did NOT contain “Valid ;”. I added that and restarted the resolver, to no effect.

However, the second line had contained a mysterious "AddPend:1540870876 ; " and when I removed that - everything started working!

Again many thanks.

I’m glad to hear it helped.

The 20326 key is the one used now, so that’s the important line, and typically I’d expect it to be still in the AddPend state for the people with broken validation. I don’t expect Turris users are interested in details of the protocol controlling the states, but it’s relatively well described.