Adguardhome: Expand/clarify DHCP options

[alexpovel]

Prerequisites

• [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

Problem Description

I'd like more control over the local domain. This is currently hard-coded to lan, see also #2393.

I'm also confused by the ip or hex requirement to the dhcpv4 field options. This only allows to set numeric values/options. I tried to broadcast the domain to DHCP clients using option 15 of the DHCP options/RFC2132, but there's no way to set the lan string. Tried with ASCII/UTF-8 codepoints, but that doesn't make any sense given how it's parsed:

https://github.com/AdguardTeam/AdGuardHome/blob/7fab31beaeb8c7d1c9892746bbf37e99d4f9dc01/internal/dhcpd/dhcpd.go#L289

which seems to only return ints?

At this point, this also goes way over my level of competence.

Proposed Solution

Add more options for the dhcpv4 field, similar to dnsmasq. This sample setup is a good description of what one could like for this, I guess.

Currently, when using the AGH as a DHCP as well as DNS server, the lan local domain works well. However, while queries to local_machine.lan are answered by the AGH locally and correcly, they are also forwarded to upstream internet servers in my setup. This is a bit confusing. Adding [/lan/]192.168.0.2, where 192.168.0.2 is the AGH machine's address, to the list of upstream DNS servers resolves this: requests are no longer forwarded. Setting 0.0.0.0 or 127.0.0.1 also works, but I don't really know what I'm doing there. At least they don't "leak out" anymore. See also #2582.

As a side effect, this for example hangs and eventually times out:

# Before, *without* [/lan/] filter
$ host local_machine.lan
local_machine.lan has address 192.168.0.50 # IMMEDIATE
Host local_machine.lan not found: 3(NXDOMAIN) # Almost immediate
#  ^ NXDOMAIN from upstream internet DNS server.
# Of course it doesn't know that domain.

# Now *with* the custom [/lan/] upstream DNS in place:
$ host local_machine.lan
local_machine.lan has address 192.168.0.50  # Again, IMMEDIATE
;; connection timed out; no servers could be reached  # 10s, then timeout

With the new [/lan/] in place, things like ssh still works instantly because I guess after the first IP arrives, it executes.

Can we have a dnsmasq-like local instruction, see the above link to the sample setup? In /etc/dnsmasq.conf, an instruction

local=/mydomain/

would never leak outside. Perfect! In addition,

domain=mydomain

would be amazing to have. Maybe throw in a domain-needed-equivalent?

Alternatives Considered

At this point, one could run a setup like #2514: if all those dnsmasq-equivalent options are needed, just run a DNS+DHCP dnsmasq server as the primary one. In it, set an AGH instance (no DHCP) as the only upstream DNS. Should work fine, just requires more stuff. For example, if running on one machine, AGH would need a port different from 53. Easy enough if not running with network_mode: host, which we only need if using DHCP. However, this setup would "require" add-mac / add-subnet, as described in that issue.

Additional Information

[ainar-g]

As you have already pointed out, the configuration of the local domain is already planned, as well as the option syntax improvements. See #2385 and also [this comment] for an example on how to set options with the current, flawed option syntax.

The forwarding of local domain requests to upstreams is a bug though, and we'll fix it. Thanks for the report!

[alexpovel]

The forwarding of local domain requests to upstreams is a bug though, and we'll fix it. Thanks for the report!

Thanks! Let me know if you'd like a dedicated issue for that, since this one is mainly about something else. Also let me know if you require more info, although this issue should be easy enough to replicate:

1. use AGH as DNS/DHCP server
2. query a local machine with hostname.lan, for example using dig
3. in the query log, observe how that request goes to upstream servers.

---

The link to your comment to hex usage clarifies things, but I was aware how that worked. The issue I'm having is that option 15 to DHCP is a string, not an int/number. As far as I can see, you can't set string values at all, because the hex values aren't interpreted as ASCII or anything, but just to decimal integers.

[ainar-g]

You can use hex for text. See #2388 for an example.

hex.DecodeString returns a slice of bytes, decoded from the hex string, and an error.