106.0 fails to resolve local domain names

[malcinator]

Have a question or an idea? Please search it on our forum to make sure it was not yet asked. If you cannot find what you had in mind, please submit it here.

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

• [ x] I am running the latest version
• [ x] I checked the documentation and found no answer
• [ x] I checked to make sure that this issue has not already been filed

Issue Details

• Version of AdGuard Home server:

  • 106.0

• How did you install AdGuard Home:

  • new release upgrade from web interface

• If it's a router or IoT, please write device model:
  Raspberry Pi 4B

• Operating system and version: *
  PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
  NAME="Raspbian GNU/Linux"
  VERSION_ID="10"
  VERSION="10 (buster)"
  VERSION_CODENAME=buster

Expected Behavior

nslookup diskstation.geek.lan

Actual Behavior

nslookup diskstation.geek.lan
Server: 192.168.1.10
Address: 192.168.1.10#53

** server can't find diskstation.geek.lan: NXDOMAIN

nslookup diskstation.geek.lan 192.168.1.10
Server: 192.168.1.10
Address: 192.168.1.10#53

** server can't find diskstation.geek.lan: NXDOMAIN

nslookup diskstation.geek.lan 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53

Name: diskstation.geek.lan
Address: 192.168.1.20

nslookup 192.168.1.20
Server: 192.168.1.10
Address: 192.168.1.10#53

20.1.168.192.in-addr.arpa name = diskstation.geek.lan.

Screenshots

Screenshot:

Additional Information

I have used diskstation.geek.lan as a typical example. I cannot resolve any local domain name on my local network.
Domain name resolution worked as expected in the previous release 105.x.

[inventorematto]

Same issue here... Cant resolve any .lan domain in etc/hosts. Changing domain to .anything-else worked for me.

[Cebeerre]

Same here. AGH is ignoring this:

[/lan/]127.0.0.1:5353

this works though:

[/vpn/]127.0.0.1:5353

I actually find this Private DNS stuff pretty confusing, I was more than fine using a config like this in the upstream servers:

[/13.168.192.in-addr.arpa/]127.0.0.1:5353
[/lan/]127.0.0.1:5353
[/0.14.10.in-addr.arpa/]127.0.0.1:5353
[/0.15.10.in-addr.arpa/]127.0.0.1:5353
[/vpn/]127.0.0.1:5353

[dioey]

same issue, i change all lan domain in MikroTik static DNS to local and it works again
changing upstream to

127.0.0.1:5335
[/local/]192.168.0.1:53

and private DNS to MikroTik DNS
192.168.0.1

[EdiTurn]

According to https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration, there is a new config local_domain_name which defines the local domain.
However, according to #3003, this function seems only work with clients from DHCP of AdGuardHome currently.

So changing this config to something else may be a workaround for now.

[Panja0]

Having the same problem after updating to 106.0

Tried every possible solution but only local IP's (PTR) will be resolved.
The other way around, resolving "machine01.panja.lan" will not be resolved anymore.

For the record: I'm using a different DHCP server in my network, not using the DHCP server on ADH.

[malcinator]

I have tried everything I can think of, which to be honest isn't much. I'm working from home and the prospect of renaming all the shortcuts I use to access my home server & NAS and then having to revert them back is not very appealing. So I have reverted back to 105.2 for now.

Just for the record and not trying to labour the point but 105.2....
nslookup diskstation.geek.lan
Server: 192.168.1.10
Address: 192.168.1.10#53

Name: diskstation.geek.lan
Address: 192.168.1.20

[HollyFredD]

I have tried everything I can think of, which to be honest isn't much. I'm working from home and the prospect of renaming all the shortcuts I use to access my home server & NAS and then having to revert them back is not very appealing. So I have reverted back to 105.2 for now.

Just for the record and not trying to labour the point but 105.2....
nslookup diskstation.geek.lan
Server: 192.168.1.10
Address: 192.168.1.10#53

Name: diskstation.geek.lan
Address: 192.168.1.20

How did you easily revert back to 105.2 ? (will do the same...)

[malcinator]

I have tried everything I can think of, which to be honest isn't much. I'm working from home and the prospect of renaming all the shortcuts I use to access my home server & NAS and then having to revert them back is not very appealing. So I have reverted back to 105.2 for now.
Just for the record and not trying to labour the point but 105.2....
nslookup diskstation.geek.lan
Server: 192.168.1.10
Address: 192.168.1.10#53
Name: diskstation.geek.lan
Address: 192.168.1.20

How did you easily revert back to 105.2 ? (will do the same...)

I did a clean installation, 5-10 mins to get it setback up again.

[Cebeerre]

I have tried everything I can think of, which to be honest isn't much. I'm working from home and the prospect of renaming all the shortcuts I use to access my home server & NAS and then having to revert them back is not very appealing. So I have reverted back to 105.2 for now.
Just for the record and not trying to labour the point but 105.2....
nslookup diskstation.geek.lan
Server: 192.168.1.10
Address: 192.168.1.10#53
Name: diskstation.geek.lan
Address: 192.168.1.20

How did you easily revert back to 105.2 ? (will do the same...)

If you did the upgrade through the UI, it creates an agh-backup directory with the previous binary and the yaml using the previous schema.

[malcinator]

I have tried everything I can think of, which to be honest isn't much. I'm working from home and the prospect of renaming all the shortcuts I use to access my home server & NAS and then having to revert them back is not very appealing. So I have reverted back to 105.2 for now.
Just for the record and not trying to labour the point but 105.2....
nslookup diskstation.geek.lan
Server: 192.168.1.10
Address: 192.168.1.10#53
Name: diskstation.geek.lan
Address: 192.168.1.20

How did you easily revert back to 105.2 ? (will do the same...)

If you did the upgrade through the UI, it creates an agh-backup directory with the previous binary and the yaml using the previous schema.

That I knew and as I don't have a complex setup reinstalling was just as easy.

[ainar-g]

Hello everyone and sorry for the confusion. It seems like we have UI and documentation issues.

The addresses from the “Private DNS servers” input are used mostly to resolve PTR requests for local IP addresses as opposed to hostnames. That is, if you do something like dig -x '192.168.12.34' '@<agh-host>', AGH uses those to resolve these queries instead of sending them to the usual upstreams. Usual requests like dig 'myhost.lan' '@<agh-host>' shouldn't be affected by this setting.

It was added to replace rules such as [/168.192.in-addr.arpa/]<my-private-dns>, so you should be able to just add your network's private DNS server there and comment out or remove those rules.

At the very least we should improve the UI and documentation on these topics, and we will in v0.106.1. Again, apologies for the confusion.

[Cebeerre]

Hello everyone and sorry for the confusion. It seems like we have UI and documentation issues.

The addresses from the “Private DNS servers” input are used mostly to resolve PTR requests for local IP addresses as opposed to hostnames. That is, if you do something like dig -x '192.168.12.34' '@<agh-host>', AGH uses those to resolve these queries instead of sending them to the usual upstreams. Usual requests like dig 'myhost.lan' '@<agh-host>' shouldn't be affected by this setting.

It was added to replace rules such as [/168.192.in-addr.arpa/]<my-private-dns>, so you should be able to just add your network's private DNS server there and comment out or remove those rules.

At the very least we should improve the UI and documentation on these topics, and we will in v0.106.1. Again, apologies for the confusion.

Thanks Ainar !

And what happened with the .lan domain ? I've had to do a rollback as well as I've references everywhere to .lan hostnames in my network, so switching to .local is quite an amount of work ...

Thanks !

[Panja0]

@ainar-g
Documentation is clear to me.
Resolving my local domain is just not working anymore.

Resolving “machine01.panja.lan” will give me a NX domain. Where before I got the right internal IP address.

So this is def. affected somewhere in the code.

[ainar-g]

@Cebeerre, @Panja0, do any of you use AGH as your network's DHCP server? If no, were those host.lan entries in your /etc/hosts files? If yes, there is probably a conflict there and changing the dns.local_domain_name might work. We're working on resolving that.

[Panja0]

@ainar-g
DHCP is not handeled by ADH, I have a pfSense box doing DHCP.

I never added anything to the host file.
I recently switched from Pihole to ADH (Docker) and after adding [/panja.lan/]ip_of_pfSense it worked perfectly.

[Cebeerre]

@Cebeerre, @Panja0, do any of you use AGH as your network's DHCP server? If no, were those host.lan entries in your /etc/hosts files? If yes, there is probably a conflict there and changing the dns.local_domain_name might work. We're working on resolving that.

No, I'm not using AGH's dhcp server ... I've an x86_64 OpenWRT router with AGH deployed on it. OpenWRT handles the dhcp and assigns hostnames based on the /etc/ethers file so the whole thing was working flawlessly just having these in the upstreams:

[/13.168.192.in-addr.arpa/]127.0.0.1:5353
[/lan/]127.0.0.1:5353

I have something similar with the IPs assigned in the VPN:

[/0.15.10.in-addr.arpa/]127.0.0.1:5353
[/vpn/]127.0.0.1:5353

and was working fine with 0.106.0, it was just messing up with the [/lan/] stuff ...

Thanks !

[malcinator]

@Cebeerre, @Panja0, do any of you use AGH as your network's DHCP server? If no, were those host.lan entries in your /etc/hosts files? If yes, there is probably a conflict there and changing the dns.local_domain_name might work. We're working on resolving that.

My router takes care of DHCP and there we no entries in /etc/hosts of my local domain name.

127.0.0.1 localhost

::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.1.1 adguard

[ainar-g]

We've pushed a fix for lan domains on machines with the DHCP server disabled as well as a better documentation message (only for the English locale for now, translations pending) to the edge channel in snapshot 59f48d7. It should fix some of these NXDOMAIN issues you're having.

[Panja0]

Good stuff @ainar-g
Nice to see fast action on such issues!
Appreciated!

[wadebenson]

I just updated my docker and this causes an issue with my .lan as well, can we get a new docker image pushed with this fix... this took down my local network. I tried to revert to an older tag but the format changed and my old config is not compatible.

[malcinator]

We've pushed a fix for lan domains on machines with the DHCP server disabled as well as a better documentation message (only for the English locale for now, translations pending) to the edge channel in snapshot 59f48d7. It should fix some of these NXDOMAIN issues you're having.

Thanks for your speed in providing a fix. But in light of the chaos it caused with my local network and issues with timemachine backups, my Plex server and access to my home server etc. to mention a few of problems I’ll be extremely cautious of installing for now.

[Panja0]

Is there any ETA for v0.106.1 @ainar-g ?
Just want to know if it’s worth downgrading for now or just wait for .1

[itsbebbo]

I have the same issue with resolving my local domain names with a non .lan domain and I am using AGH as the DHCP server. I've found that changing the dns.local_domain_name to anything other than my actual domain allows it to work!
There is definitely something funky going on with AGH refusing to resolve the domain set here whether you are using it as a DHCP server or not. I assume that now I have this set to something other than my domain it will prevent the DHCP server from correctly naming clients and won't prevent DNS queries for my domain being sent out for recursive resolution on the internet?

[ainar-g]

v0.106.1 has been released. It includes the fix for the *.lan hosts on non-DHCP AGH installations.

[itsbebbo]

Has this fixed the issue where AGH fails to resolve any domain you list in local domain name even where used as a DHCP server or if it's it just for .lan?

[wadebenson]

v0.106.1 has been released. It includes the fix for the *.lan hosts on non-DHCP AGH installations.

This fixed my issue thank you.

[Panja0]

@ainar-g
Many thanks for pushing this update, this fast!
I can confirm everything is working again after updating to v0.106.1
Though I have to put [/panja.lan/]ip_of_pfsense as upstream DNS server. But this is probably supposed to, right?! (like it was on v0.105.2).

[jbrodriguez]

Though I have to put [/panja.lan/]ip_of_pfsense as upstream DNS server. But this is probably supposed to, right?! (like it was on v0.105.2).

I removed that (similar) line from upstreams and it works great, I just put it in private dns server

[Panja0]

@jbrodriguez
I have added the Private DNS server, like you did.
This works great for PTR request e.g. looking up (internal) IP addresses but it does not work for resolving local domains (e.g. panja.lan)

I still have to put [/panja.lan/]ip_of_pfsense as upstream if I want to resolve for instance machine01.panja.lan
Which makes sense though.

[ainar-g]

The [/.lan/] upstream has to stay for now, because Private DNS Servers are only used for PTR requests, not for the usual ones, so @Panja0 should keep it for now. But [/168.192.in-addr.arpa/] ones can be removed and replaced with the Private DNS Servers.

It seems like the main issue with .lan for people without DHCP is resolved, so we'll close this issue. If anyone has any questions after that, they are better off in GitHub Discussions.

[jelbo]

I fixed this myself yesterday by changing local_domain_name: lan to local_domain_name: somethingelse in AdGuardHome.yaml.

[shawly]

This issue still persists as it seems. My AGH installation is used as DHCP server but as soon as I change local_domain_name: lan to local_domain_name: lan.mydomain.net I cannot resolve any of my CNAME or A records for lan.mydomain.net anymore...

[Ziggy815]

This issue still persists as it seems. My AGH installation is used as DHCP server but as soon as I change local_domain_name: lan to local_domain_name: lan.mydomain.net I cannot resolve any of my CNAME or A records for lan.mydomain.net anymore...

Exactly the same here

[Petro31]

Can confirm, having the exact same issue.

[truehumandesign]

Same issue here!

[home4lab]

i just input 1 line like this, and i can resolve our local dns with local ip

[ainar-g]

@shawly, apologies, your message seems to have slipped through the cracks. Is lan.mydomain.net in your example publicly available or is known to e.g. your router's DNS server?

[EpicLPer]

Same issue here too... sometimes name resolution of internal addresses like "xyz.local" works, but other times only "xyz" without anything works. Really spotty tho what does and what doesn't...

[icaroscherma]

i just input 1 line like this, and i can resolve our local dns with local ip

If you don't want a local domain (.local, .lan ...) you just want to type something like ping mydellserver and it resolves automatically, the reply from @home4lab is the right one.

You need to add your router as the first Upstream DNS server, I did it with a UDM-SE (Unifi) and with a PfSense and they both worked fine.

Just remember to flush your local dns on your machine once you push theses changes.

Windows:

ipconfig /flushdns

MacOS:

sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder

For Linux it depends what you're using, if it's Ubuntu-like:

sudo systemd-resolve --flush-caches

[ErikvdVen]

No luck with any previous recommendations whatsover. I'm using HAProxy to guide my own domain, whenever it is used within my LAN, to redirect it directly to local services: so the IP of someservice.mydomain.com will not be 99.111.123.23 or whatever, but 192.168.1.3

Now, after changing my Unbound DNS port from 53 to 5353, it doesn't work anymore. I've followed the steps like entering 192.168.1.1:5353 as private reverse dns server and adding that one to the upstream dns servers, but no luck whatsoever.

Also adding [/subdomain.mydomain.com/]192.168.1.1:5353 to upstream dns servers, didn't work. For now I've disabled Adguard, until anyone has a possible solution?