"Skipping invalid hostname" with a trailing zero-byte

[alexpovel]

Prerequisites

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

Issue Details

• Version of AdGuard Home server:
  • v0.104.3 (also happens in v0.105.1)
• How did you setup DNS configuration:
  • AGH is only DNS as well as DHCP server in local network
• Operating system and version:
  • Running in Docker with latest image on x86 Debian host, network_mode = host

Expected Behavior

Local hostname that is managed by AGH's DHCP server to be accepted by DNS resolution properly.

Actual Behavior

Local machine is registered in DHCP server correctly and receives a lease, however is skipped in DNS due to "invalid hostname". There is only one machine where this happens, all others are accepted by DHCP fine, get a lease and are henceforth resolvable correctly from hostname.lan thanks to the local TLD.

The machine in question is a Synology DS218+. Setting the hostname via its web GUI or via SSH using

user@nas:~$ sudo synonet --set_hostname nas
change hostname to: nas
done

succeeds in itself.

Due to mDNS, the machine is reachable at nas.local afterwards, but not under nas.lan.

The machine receives an IP and its network config from AGH's DHCP server. From the Docker logs:

[debug] Clients: added "192.168.0.53" -> "nas\x00" [15]

However, any other machine looking up that hostname at nas.lan receives:

$host nas.lan
Host nas.lan not found: 3(NXDOMAIN)

The AGH DNS server actually forwards this request to upstream servers.

Any other local machine, say with hostname hello works just fine:

$host hello.lan
hello.lan has address 192.168.0.50
Host hello.lan not found: 3(NXDOMAIN)

This is also forwarded to upstream servers, hence the second NXDOMAIN, but at least we get a local response from AGH's DNS server since it recognizes that local host (to whom it leased an IP) with its lan domain. Why it is also sent upstream is another question, maybe a missing config in my setup where I could use a custom upstream filtering rule for the lan domain.

The important question (and topic of this issue) is why lookup of nas.lan fails, while all other host.lan lookups succeed. I think the issue lies with the trailing zero-byte when the DHCP lease happens: nas\x00. This is straight from the logs. I don't know where this stems from. The \x00 happens with no other host. This is most apparant at container start-up when AGH reloads leases from its workdir DB (persistent through a volume):

2021/01/20 21:21:02 1#1 [debug] Clients: added "192.168.0.50" -> "hello" [1]
2021/01/20 21:21:02 1#1 [debug] Clients: added "192.168.0.51" -> "world" [2]
2021/01/20 21:21:02 1#1 [debug] Clients: added "192.168.0.53" -> "nas\x00" [3]

On the nas machine, I can run:

$ hostname | od -A n -t x1
6e 61 73 0a

hence ASCII/UTF-8 nas\LF, the expected sequence. On the working host of hello, we see the same result (hello in ASCII/UTF-8 with a linefeed. No sign for zero-bytes).

It is entirely possible that the trailing zero-byte is not the culprit, but it's my best bet right now. It's also entirely possible it's not added by AGH but somewhere in transit (hence the NAS's fault). In the latter case, I still wonder if a simple strip(hostname) would do, stripping legit whitespace but also zero-bytes (and maybe other crap)?

[ainar-g]

Hi, and thank you for your report! Can you please show the output of the following two commands on the Synology machine?

od -A n -t x1 /etc/hosts

arp -a | od -A n -t x1

[alexpovel]

Thanks for your reply. The outputs are:

---

od -A n -t x1 /etc/hosts

$ od -A n -t x1 /etc/hosts
 23 20 41 6e 79 20 6d 61 6e 75 61 6c 20 63 68 61
 6e 67 65 20 77 69 6c 6c 20 62 65 20 6c 6f 73 74
 20 69 66 20 74 68 65 20 68 6f 73 74 20 6e 61 6d
 65 20 69 73 20 63 68 61 6e 67 65 64 20 6f 72 20
 73 79 73 74 65 6d 20 75 70 67 72 61 64 65 73 2e
 0a 31 32 37 2e 30 2e 30 2e 31 09 6c 6f 63 61 6c
 68 6f 73 74 0a 3a 3a 31 09 09 6c 6f 63 61 6c 68
 6f 73 74 0a 31 32 37 2e 30 2e 30 2e 31 09 61 63
 70 6e 61 73 0a 3a 3a 31 09 09 61 63 70 6e 61 73
 0a

with

$ cat /etc/hosts
# Any manual change will be lost if the host name is changed or system upgrades.
127.0.0.1       localhost
::1             localhost
127.0.0.1       acpnas
::1             acpnas

So please note that the real hostname is acpnas, not nas. I had changed/redacted that originally, but for the sake of fixing this that's not really feasible anymore. Should hopefully not make a difference, since there's no zero-bytes in there either.

---

arp -a | od -A n -t x1

$ arp -a | od -A n -t x1
 3f 20 28 31 39 32 2e 31 36 38 2e 31 33 37 2e 35
 32 29 20 61 74 20 3c 69 6e 63 6f 6d 70 6c 65 74
 65 3e 20 6f 6e 20 65 74 68 30 0a 3f 20 28 31 39
 32 2e 31 36 38 2e 31 33 37 2e 36 33 29 20 61 74
 20 35 30 3a 65 30 3a 38 35 3a 30 38 3a 30 62 3a
 32 39 20 5b 65 74 68 65 72 5d 20 6f 6e 20 65 74
 68 30 0a 3f 20 28 31 39 32 2e 31 36 38 2e 31 33
 37 2e 35 31 29 20 61 74 20 31 63 3a 36 39 3a 37
 61 3a 30 33 3a 31 66 3a 33 62 20 5b 65 74 68 65
 72 5d 20 6f 6e 20 65 74 68 30 0a 3f 20 28 31 39
 32 2e 31 36 38 2e 31 33 37 2e 32 29 20 61 74 20
 64 63 3a 61 36 3a 33 32 3a 63 35 3a 63 37 3a 64
 34 20 5b 65 74 68 65 72 5d 20 6f 6e 20 65 74 68
 30 0a 3f 20 28 31 39 32 2e 31 36 38 2e 31 33 37
 2e 31 29 20 61 74 20 64 63 3a 33 39 3a 36 66 3a
 66 30 3a 39 61 3a 62 30 20 5b 65 74 68 65 72 5d
 20 6f 6e 20 65 74 68 30 0a 70 6f 76 65 6c 2d 6c
 61 70 74 6f 70 20 28 31 39 32 2e 31 36 38 2e 31
 33 37 2e 36 34 29 20 61 74 20 39 38 3a 66 61 3a
 39 62 3a 63 30 3a 61 63 3a 31 66 20 5b 65 74 68
 65 72 5d 20 6f 6e 20 65 74 68 30 0a 3f 20 28 31
 36 39 2e 32 35 34 2e 32 33 34 2e 31 39 36 29 20
 61 74 20 39 38 3a 66 61 3a 39 62 3a 63 30 3a 61
 63 3a 31 66 20 5b 65 74 68 65 72 5d 20 6f 6e 20
 65 74 68 30 0a 6e 75 63 63 69 20 28 31 39 32 2e
 31 36 38 2e 31 33 37 2e 34 29 20 61 74 20 31 63
 3a 36 39 3a 37 61 3a 30 33 3a 31 66 3a 33 62 20
 5b 65 74 68 65 72 5d 20 6f 6e 20 65 74 68 30 0a

The local net is 192.168.137.1/24.

[ainar-g]

Thanks for the info! We'll dig further.

[EugeneOne1]

Unfortunately, we couldn't reproduce the issue but we've tried to fix it anyway as of snapshot 8ead755. Could you please check, if our solution works properly for you?

[alexpovel]

Thanks for getting back to this issue. Running the current edge Docker image (v0.106.0-SNAPSHOT-8ead755b) did not solve it, the behaviour is still as above, with a trailing \x00 added when the host is entered into the DHCP list of known hosts. So I'm sorry to report that nothing changed.

[EugeneOne1]

Well, that's sad. We'll dig further and try to solve it as soon, as possible. Thanks for your patience :)

[alexpovel]

Thanks, no worries. Adding a permanent DHCP lease for that machine and adding a manual hostname of acpnas.lan works fine, it's just not pretty. And since you can't reproduce it, it's hard. Some more info towards that:

The AGH server runs in a docker-compose service:

version: "3.2"

volumes:
  work:

services:
  main:
    # For configs, see https://hub.docker.com/r/adguard/adguardhome
    build: .
    container_name: adguard
    network_mode: host  # Required for DHCP server
    volumes:
      # No config volume because we bake that into the image
      - work:/opt/adguardhome/work
    restart: unless-stopped

The Dockerfile to build is:

# Ansible managed

FROM adguard/adguardhome

COPY adguard.yml /opt/adguardhome/conf/AdGuardHome.yaml
COPY allowlist /lists/allowlist

Where adguard.yml is:

# Ansible managed


bind_host: 0.0.0.0
bind_port: 80
users:
- name: "user"
  password: "password"
http_proxy: ""
language: ""
rlimit_nofile: 0
debug_pprof: false
web_session_ttl: 720
dns:
  bind_host: 0.0.0.0
  port: 53
  statistics_interval: 30
  querylog_enabled: true
  querylog_file_enabled: true
  querylog_interval: 90
  querylog_size_memory: 1000
  anonymize_client_ip: false
  protection_enabled: true
  blocking_mode: nxdomain
  blocking_ipv4: ""
  blocking_ipv6: ""
  blocked_response_ttl: 3600  # Blocked remains blocked, we do not "change filters often"
  parental_block_host: family-block.dns.adguard.com
  safebrowsing_block_host: standard-block.dns.adguard.com
  ratelimit: 20
  ratelimit_whitelist: []
  refuse_any: true
  upstream_dns:
  - https://dns.digitale-gesellschaft.ch/dns-query
  - https://dns.quad9.net/dns-query
  - https://doh.opendns.com/dns-query
  upstream_dns_file: ""
  bootstrap_dns:
  - 9.9.9.10
  - 149.112.112.10
  - 2620:fe::10
  - 2620:fe::fe:10
  all_servers: false
  fastest_addr: true
  allowed_clients: []
  disallowed_clients: []
  blocked_hosts:
  - version.bind
  - id.server
  - hostname.bind
  cache_size: 4194304
  cache_ttl_min: 0
  cache_ttl_max: 0
  bogus_nxdomain: []
  aaaa_disabled: false
  enable_dnssec: true
  edns_client_subnet: false
  max_goroutines: 300
  ipset: []
  filtering_enabled: true
  filters_update_interval: 24
  parental_enabled: false
  safesearch_enabled: false
  safebrowsing_enabled: false
  safebrowsing_cache_size: 1048576
  safesearch_cache_size: 1048576
  parental_cache_size: 1048576
  cache_time: 30
  rewrites:
  - domain: my.router
    answer: 192.168.137.1
  blocked_services: []
tls:
  enabled: false
  server_name: ""
  force_https: false
  port_https: 443
  port_dns_over_tls: 853
  port_dns_over_quic: 784
  allow_unencrypted_doh: false
  strict_sni_check: false
  certificate_chain: ""
  private_key: ""
  certificate_path: ""
  private_key_path: ""
filters:
- enabled: true
  url: https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt
  name: AdGuard DNS filter
  id: 1
- enabled: true
  url: https://adaway.org/hosts.txt
  name: AdAway Default Blocklist
  id: 2
- enabled: true
  url: https://sysctl.org/cameleon/hosts
  name: https://old.reddit.com/r/de_EDV/comments/j80tnz/pihole_aufgesetzt_wie_weiter_optimieren/g885fnm/
  id: 1000000
- enabled: true
  url: https://adaway.org/hosts.txt
  name: Exported from PiHole 01
  id: 1000001
# more lists...
whitelist_filters:
- enabled: true
  url: /lists/allowlist
  name: Custom allowlist
  id: 1610956463
user_rules: []
dhcp:
  enabled: True
  # The container will run in `network_mode = host`, so the interfaces have to agree:
  interface_name: eth0
  dhcpv4:
    gateway_ip: 192.168.137.1
    subnet_mask: 255.255.255.0
    range_start: 192.168.137.50
    range_end: 192.168.137.254
    lease_duration: 3600 # default: 86400 (24h)
    icmp_timeout_msec: 1000
    options:
      - "6 hex \
                  c0a8890a\
                  c0a8890b\
        "
  dhcpv6:
    range_start: ""
    lease_duration: 86400
    ra_slaac_only: false
    ra_allow_slaac: false
clients: []
log_compress: false
log_localtime: true
log_max_backups: 0
log_max_size: 100
log_max_age: 3
log_file: ""
verbose: true
schema_version: 7

This runs on a completely vanilla Raspbian OS Raspbian Pi 4 8GB. Super vanilla setup. The only notable thing is maybe that the homenet is 192.168.137.0/24, not a standard one.

Note: all this is Ansible managed, and if you have a Pi laying around (or any machine really) you could replicate my exact setup using my exact Ansible collection, see the adguard role.

(This is also the reason I went with AGH: configuring via YAML a priori is fantastic and a strict requirement when employing with Ansible -- PiHole simply can't do this out of principle, they don't have an elaborate a priori config.)

[EugeneOne1]

We've inspected the source of the issue and came up with the version, that there is a bug in one of the libraries we use. Could you please check our solution (snapshot 5aa0ca9) again? If it works, we're going to leave a PR to that library repo and mention this issue.

[alexpovel]

Works! Thanks a ton. This issue is part of milestone v0.105.2, so will its fix be part of that version or will you change that since it's an upstream lib PR?

[ainar-g]

The current plan is to release the fix in AdGuard Home with v0.105.2, yeah. We'll update our code and remove our workaround once the module's maintainers merge the fix.

If the solution works, I'll close this issue. Again, thanks for the report.

[EugeneOne1]

Hello again! As you can see, our improvement is now merged and we've just removed our temporary workaround. Can we ask you to check for the very last time (I hope) if it works properly with your unique configuration as of snapshot 2c9992e?

[alexpovel]

Thanks for getting back to this. Testing with v0.106.0-a.51+2c9992e0 it does in fact not work! To make it work, I have to register the machine as a static DHCP lease, the original workaround. Otherwise, the behaviour is broken as before.

[EugeneOne1]

Yeah, we've introduced this embarrassing bug again. Fortunately, we've already prepared another little fix, wait for it in a couple of hours. Sorry about that.

[EugeneOne1]

Finally, the fix is in the snapshot 4c6bf68. Could you please check it?

[alexpovel]

Yep, that snapshot looks good, thanks.

[EugeneOne1]

Glad to hear that! :)