dnsmasq doesn't resolve .local domains
jostyee opened this issue · 20 comments
After installation, I get default settings as below:
[/local/][::]:553
[/localdomain/][::]:553
and dnsmasq is listening on port 553 correctly.
nslookup my-mbp.local 192.168.1.1:553
Server: 192.168.1.1
Address 1: 192.168.1.1 Router.local
Name: my-mbp.local
Address 1: 192.168.1.4 my-mbp.local
But somehow the requests to lan devices are leaking to upstream server
Is there anyway I can debug it? Thanks in advance.
@jostyee , Sure please share a screenshot of your adguardhome upstream configuration and Private reverse resolver configuration sections.
The weird thing is it shows your request being sent to nextdns. Also if you don't mind, please share the contents of your AdGuardHome.yaml
e.g. cat /opt/etc/AdGuardHome/AdGuardHome.yaml
Here is a thread for you to take a look at -
https://www.snbforums.com/threads/adguard-blocked-local-domain-queries.81284/
@jumpsmm7 my upstream/rDNS config part:
upstream_dns:
- '[/router.asus.com/][::]:553'
- '[/www.asusnetwork.net/][::]:553'
- '[/www.asusrouter.com/][::]:553'
- '[/use-application-dns.net/][::]:553'
- '[/dns.resolver.arpa/][::]:553'
- '[/local/][::]:553'
- '[/localdomain/][::]:553'
- '[//][::]:553'
- [/plex.direct/]1.1.1.1
- https://dns.nextdns.io/redacted
...
local_ptr_upstreams:
- '[::]:553'
- '[/10.in-addr.arpa/][::]:553'
- '[/168.192.in-addr.arpa/][::]:553'
I guess AdGuard Home doesn't forward local requests to :553 ?
@jumpsmm7 my upstream/rDNS config part:
upstream_dns: - '[/router.asus.com/][::]:553' - '[/www.asusnetwork.net/][::]:553' - '[/www.asusrouter.com/][::]:553' - '[/use-application-dns.net/][::]:553' - '[/dns.resolver.arpa/][::]:553' - '[/local/][::]:553' - '[/localdomain/][::]:553' - '[//][::]:553' - [/plex.direct/]1.1.1.1 - https://dns.nextdns.io/redacted ... local_ptr_upstreams: - '[::]:553' - '[/10.in-addr.arpa/][::]:553' - '[/168.192.in-addr.arpa/][::]:553'
try changing from .local to something like ".lan" and remove the localdomain line from your upstream. see what happens, tell me if it fixes the issue. The problem i think is coming from .local being intended for a ZERO configuration DNS, not an actual DNS resolver. IEFT says it is for special use cases as such. Meaning it can leak upstream if you are not careful. I am just requesting you to test it out to see if the issue goes away.
It is intended for multicast networking, which means it can leak upstream.
local networks are intended to be unicast, (with the exception of IPV6). meaning .local can communicate over ipv6 networks for neighbor solicitations.
The [Internet Engineering Task Force](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) (IETF) reserves the use of the domain name label .local as a [special-use domain name](https://en.wikipedia.org/wiki/Special-use_domain_name) for hostnames in local area networks that can be resolved via the [Multicast DNS](https://en.wikipedia.org/wiki/Multicast_DNS) name resolution protocol.[[2]](https://en.wikipedia.org/wiki/.local#cite_note-rfc6762-2) Any DNS query for a name ending with the label local must be sent to the mDNS IPv4 link-local multicast address 224.0.0.251, or its IPv6 equivalent ff02::fb. A domain name ending in .local may be resolved concurrently via other mechanisms, for example, unicast DNS.
you can try a domain name like ".lan" to test the theory.
To sum it up-From what I read, the whole issue may be being caused by your use of the domain name ".local" which can be resolved by both multicast DNS and unicast DNS concurrently. So the issue doesn't reside with adguardhome. AdGuardHome is adhering to the IEFT DNS standards. Here you are experiencing an unfortunate side effect of using the domain name of ".local" and "localdomain".
When an mDNS client needs to resolve a hostname, it sends an [IP multicast](https://en.wikipedia.org/wiki/IP_multicast) query message that asks the host having that name to identify itself. That target machine then multicasts a message that includes its IP address. All machines in that subnet can then use that information to update their mDNS caches. Any host can relinquish its claim to a name by sending a response packet with a [time to live](https://en.wikipedia.org/wiki/Time_to_live) (TTL) equal to zero. By default, mDNS exclusively resolves hostnames ending with the [.local](https://en.wikipedia.org/wiki/.local) top-level domain. This can cause problems if .local includes hosts that do not implement mDNS but that can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that mDNS was designed to avoid.
So essentially, you need to use something other than ".local"
Sorry for being noob but after I changed router's domain name to lan I can't connect other devices by local domains any longer.
❯ ping joes-mbp.lan
ping: cannot resolve joes-mbp.lan: Unknown host
❯ hostname
joes-mbp.lan
@jumpsmm7 agh still asks remote upstream server for resolving
updated agh config:
upstream_dns:
- https://dns.nextdns.io/redacted
- '[/router.asus.com/][::]:553'
- '[/www.asusnetwork.net/][::]:553'
- '[/www.asusrouter.com/][::]:553'
- '[/use-application-dns.net/][::]:553'
- '[/dns.resolver.arpa/][::]:553'
- '[/lan/][::]:553'
- '[//][::]:553'
@jostyee
This is correct:
Make sure you save it in the Web UI.
Next you need to edit adguardhome. Change the values from the image in your upstream section. Save it.
should look like.
then issue the SSH terminal command
service restart_AdGuardHome
@jumpsmm7 I've already modified my agh config as you suggested, even restarted router, but it's just not working. :-(
That is all the feedback I have, if none of it works, then there is something Unique about your setup that neither one of us understands, or adguardhome itself is doing something it shouldn't( that would mean the issue needs to be open with adguardhome github https://github.com/AdguardTeam/AdGuardHome/issues).
https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration
You have to dig into adguardhomes configuration wiki and figure it out on your own by comparing their guide to your setup. feel free to share what you find. As far as I am aware of, I have the installer setup per their configuration method following standard methods.
@jumpsmm7 thanks for your patience, I'm really grateful. Will report back later if I figure out the reason.
@jumpsmm7 sorry but one more question, does the order of upstream_dns matter as you said at #180 (comment) ? I'm using Parallel requests
Parallel requests and order might definitely have something to do with it. you are welcome to play around with it. That is why i mentions moving the order around to see if it changes anything. However their wiki says otherwise.
See the order they list things and their logic on how the responses should be handled-
This leads me to think something may be broken upstream with AdGuardHome.
if it is not too much trouble to ask, how are you making this look up request?
is the requesting client connected within onehop of the network (meaning physically connected to LAN), or are you connected remotely making the request? Remote connections cannot resolve local addresses, which is an intended safety feature of adguardhome.
@jumpsmm7 I restarted all my devices & it works now, maybe need to do DHCP lease manually.
Thanks again for being so helpful. :-)
@jumpsmm7 I restarted all my devices & it works now, maybe need to do DHCP lease manually.
Thanks again for being so helpful. :-)
For future reference, remember to steer clear of using .local . You were right about the client leases needing to be refreshed. Sometimes rebooting the router is simple enough to do the job, but sometimes it isnt.