Ability to disable /etc/hosts resolving

[vin047]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to report a bug and not ask a question or ask for help

• I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

Linux, AMD64 (aka x86_64)

Installation

GitHub releases or script from README

Setup

Other (please mention in the description)

AdGuard Home version

v0.107.43

Action

nslookup adguard.example.com

Expected result

IP address of my AdGuard Home instance, which is fetched from an upstream DNS server.

Actual result

IP address from the system hosts file is returned instead.

Additional information and/or screenshots

I have an upstream DNS server which contains the records of all my devices on my network. AdGuard Home is configured to use this upstream server and has its cache disabled, so it always queries upstream whenever I request a DNS record for a device on my network. All works well except when requesting the DNS record for the AdGuard instance itself – it always returns the IP address for the AdGuard instance from the hosts file instead of querying upstream.

• I can see in the logs that the DNS record is being rewritten by "Rule: System hosts file".
• /etc/hosts does indeed contain the "incorrect" IP.
• I had previously set clients.runtime_sources.hosts: false and rebooted.
• This was working fine on v0.107.35 – hosts file was ignored thanks to disabling hosts as a runtime source and the IP address was fetched from upstream. I upgraded to v0.107.43 (accidentally mind you – the web interface really should show a confirmation button when you click upgrade!) and it stopped working.
• I have tried shutting down the service, changing clients.runtime_sources.hosts: true, starting the service again, then turning the service off again, changing it back to false, then starting the service again. Same result.
• Removing the incorrect IP from /etc/hosts works but of course isn't the solution.

[1432447293]

I solved the problem after reinstalling

[ainar-g]

Removing the incorrect IP from /etc/hosts works but of course isn't the solution.

Why isn't it though? Every other DNS resolver would probably use the information from there first. What's the point of having an incorrect hostname-IP link in your /etc/hosts?

[Dennis14e]

In my case, /etc/hosts only contains "localhost" and the hostname of the current host.
For me, the data from one of my upstream DNS servers (Microsoft DCs) has a higher priority than the local data (in case the local data is incorrect).

[tjharman]

I don't quite follow this thread.

Is clients.runtime_sources.hosts=false supposed to work, or are we supposed to use --no-etc-hosts ?

The reason I don't want /etc/hosts to be read is I use split-horizon DNS, and I host websites on the same server I run my AdguardHome.

When I'm out on the road, remote (offnet) clients are cofigured to use a public DNS server, and thus I want the public IP address returned of my webserver. Because it's reading /etc/hosts though it's saying that my public website's IP is 192.168.0.5 which obviously doesn't work.

I want all AdGuardDNS to be driven by DNS requests, not /etc/hosts lookup.

I'm using AdGuardHome v0.107.43 and I have found that setting clients.runtime_sources.hosts=false does not currently work with the stable version. I've a workaround where I can either disable my adguard DNS server in my Android Settings, or turn on a VPN (and thus appear in the 192.166 subnet) to get to my websites on my mobile, but I'm keen to see what the proper solution is here.

Many thanks for your hard work on this great project.

[ainar-g]

clients.runtime_sources.hosts is supposed to do what it says on the tin: enable or disable the use of /etc/hosts in identifying clients at runtime. Ignoring /etc/hosts sounds like a rare use-case for most people, so, before we start adding boolean flags, we need to know what problems people want to solve.

The reason I don't want /etc/hosts to be read is I use split-horizon DNS, and I host websites on the same server I run my AdguardHome.

When I'm out on the road, remote (offnet) clients are cofigured to use a public DNS server, and thus I want the public IP address returned of my webserver. Because it's reading /etc/hosts though it's saying that my public website's IP is 192.168.0.5 which obviously doesn't work.

Thanks for this example. --no-etc-hosts is probably what you're looking for. If there is enough demand, we'll probably add that to the configuration file as well.

[tjharman]

@ainar-g Thank you very much - I'm sorry I'd missed the subtle difference with clients.runtime_sources.hosts being used to identify clients, not as a lookup source.

I will test with --no-etc-hosts it sounds exactly what I'm after.

Thank you for taking the time to response/clarify, I appreciate it.

[Dennis14e]

If clients.runtime_sources.hosts and --no-etc-hosts is not the same, then I don't get this warning:

AdGuardHome/internal/home/options.go

Lines 270 to 274 in 8936c95

	log.Info(
	"warning: --no-etc-hosts flag is deprecated " +
	"and will be removed in the future versions; " +
	"set clients.runtime_sources.hosts in the configuration file to false instead",
	)

[tjharman]

@Dennis14e Yes that was confusing me too, but I expect that's why it's depreciated and not removed as they're not 100% functionally similar.

I can confirm that --no-etc-hosts works for me and resolves my problem when using a dedicated public DNS server as my upstream, the proper public IP of my host is returned, not the ip in /etc/hosts.

My only last question is, I'm running the current stable build, do I need to worry about this PR?

I have Zabbix monitoring my AdGuardHome process, so if it dies I'll know, but probably the family will scream at me a bit first :-)

Thanks again for a great bit of software, it really is a must-have!

[vin047]

Removing the incorrect IP from /etc/hosts works but of course isn't the solution.

Why isn't it though? Every other DNS resolver would probably use the information from there first. What's the point of having an incorrect hostname-IP link in your /etc/hosts?

I run AdGuard Home in an LXC container on Proxmox. By default, Proxmox modifies the /etc/hosts file of a container every time it starts (docs), by setting the hostname to a loopback address. TBH i'm not sure why it does that and there is a workaround in the linked docs to disable this behaviour, which is what i'm currently using.

But regardless of what Proxmox is doing, the fact remains that the behaviour of AdGuard Home has changed: with clients.runtime_sources.hosts: false my /etc/hosts file used to be ignored, but since updating, it no longer is ignored. Hence I reported it as it seemed like a bug to me.

clients.runtime_sources.hosts is supposed to do what it says on the tin: enable or disable the use of /etc/hosts in identifying clients at runtime.

Perhaps the previous behaviour was bugged then but has now been fixed. But like others have mentioned, the docs are confusing as it seems like --no-etc-hosts does ignore the hosts file, and as it has been replaced by clients.runtime_sources.hosts, one would expect setting it to false to ignore the hosts file too.

[ainar-g]

Thanks for the feedback. We'll probably add this feature to the configuration file.

[mattxtaz]

If you need another use case for this. I've just come across this problem. I run AGH in a podman container and it adds host.containers.internal host.docker.internal to the /etc/hosts file inside the container. This means that any reverse DNS lookups of my servers IP comes back as that fake internal hostname rather than the real hostname:

% host 10.0.0.10
10.0.0.10.in-addr.arpa domain name pointer host.containers.internal.
10.0.0.10.in-addr.arpa domain name pointer host.docker.internal.

So I would also like to disable AGH reading /etc/hosts. Fixed by adding --no-etc-hosts to the containers Exec arguments (for now!)

[schzhn]

We've pushed the edge release that adds a new property dns.hostsfile_enabled to the configuration file.
This property can disable the use of the system hosts file for query resolution.

[tjharman]

Thanks very much, I'll give this a test. Appreciate the fact you've added this.

[tjharman]

I meant to report back and thank you for dns.hostsfile_enabled
Works perfectly.