after the core 144 update I notice regular problems with resolving local DNS names (or similar).
I have configured some hosts in ipfire, e.g. server1.local_domain. Several times a day my browser tells me “website not found” when trying to connect to server1.local_domain, ping server1.local_domain tells “name or service not found”. There are more services having this problem, some do not.
server1.local_domain does not work but e.g. server2.local_domain, but maybe server2.local_domain will not work later, too
Edit: it could be that connection to server1.local_domain works from client 1 but not from client 2
There is no problem with domains in the internet
This problem was noticed for clients in my local network and for mobile devices via OpenVPN
This state remains for a while, maybe it works again later
I can force it working again when disconnection the client device from network and connect it again
Does anyone see similar problems? I have no idea what the problem could be. I scanned manually the logs but can’t find any interesting entries…
there currently is a patch in the queue for
the next Core Update to change Unbounds resolution behaviour on locally configured hosts.
Perhaps this will fix your problem.
Meanwhile, what does a dig a server1.local_domain return if things do not work? NXDOMAIN or SERVFAIL?
Could you post all log lines in /var/log/messages containing unbound here, please?
In case of SERVFAILs, it should log there why a query could not be answered.
these log lines are most likely caused by SERVFAILs:
Apr 29 09:18:52 ipfire unbound: [22374:0] info: validation failure <local. SOA IN>: no NSEC3 records from 80.241.218.68 for DS local. while building chain of trust
Apr 29 13:50:28 ipfire unbound: [22374:0] info: validation failure <local. SOA IN>: no DNSSEC records from 176.9.93.198 for DS local. while building chain of trust
Since .local is reserved for multicast DNS, I guess it’s best to switch to a
different internal domain as leaking mDNS queries to DNS is neither robust nor
desirable.
You will notice that the query that succeeds is an IPv4 query, while the one that fails is an IPv6 query.
I am not sure what has changed, yet. I have not made changes to my host (Ubuntu 19.10), but an update may have.
It seems, however, that Unbound does not respond correctly to the AAAA request and instead of returning what is in the hosts settings, it returns the results from the authoritative nameserver on the internet.
I would, if I knew how to apply the patch. It looks like it is a patch for the IpFire build system.
Maybe you could tell me what to change in which file(s) on my IpFire?
I am still not sure why this started at all. I have been tracking two of my systems for a while now. One, Ubuntu 20.04, has not sent an AAAA query once, while my Ubuntu 19,10 machine has several times. Even though I have disabled IPv6 entirely!
The whole problem seems to be that my system asks for an IPv6 address every once in a while. I have no idea why. I don’t know if it did before, or if it didn’t, when it started.
I have not changed my network settings. Maybe it will go away when I upgrade to Ubuntu 20.04 when the .1 release is here.
this sounds like Ubuntu asks for an IPv6 address first, and falls back to IPv4 if
the query did not return any sufficient response. Since there is only an IPv4 address
configured locally, the other query will be emitted to an external resolver.
Even when using core utilities like host, an IPv6 DNS query is being made:
user@machine:~> host example.com
example.com has address 93.184.216.34
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 0 .
There are two problems about this:
We cannot predict the applications’ behaviour. Some applications might ask
for an IPv6 address first, some do not, some query for v4 and v6 in parallel.
In your case, you probably want any query to a locally configured host to
return NXDOMAIN, except for IPv4 queries. Some other people apparently need
to forward the former to external resolvers, which breaks you setup and vice
versa.
I have no good idea about what to on this. Adding another switch somewhere in the
WUI would make things more complicated and confusing.
Unbound is just handling this awfully wrong here. I assumed that it would do something else from what the documentation says.
When the system queries for a name and there is no AAAA record, it cannot return NXDOMAIN. That would mean that nothing exists under that name which is not true. In this example, an A record exists, but the client’s DNS resolver has been told that nothing exists and therefore it is not trying any more.
So, the client is behaving correctly. Unbound isn’t. The patch will fix it. We need to get it into the next update.
