[Bug] Service Fails to Start

[zero77]

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

Snapcraft

Setup

Other (please mention in the description)

AdGuard Home version

v0.108.0-a.861+14c6be3b

Action

On a reboot or service restart the AdGuard Home snap service fails to start and only shows the two errors below.
After doing some more investigating i found that if i add another dns server to the resolv file and try to start the service again it works.

So it looks like AdGuard Home will not start if it's the only dns server configured in resolv and the upstream or fall back dns settings don't make a difference.

I am using Debian and have the below dns settings configured:

/etc/resolv.conf
nameserver 127.0.0.1

The errors below are the only errors i have found:
/var/log/syslog
adguard-home.adguard-home[170191]: [error] querylog: closing: flushing log buffer: nothing to write to a file adguard-home.adguard-home[170191]: [fatal] dnsServer.Prepare: setting up resolvers: creating local resolvers: validating general upstreams: no upstream specified

Expected result

The AdGuard Home snap service should start automatically after a reboot or service restart , even if it's the only dns server configured on the host in resolv.

Actual result

The AdGuard Home snap service fails to start when it is the only dns server configured on the host in resolv.

Additional information and/or screenshots

No response

[EugeneOne1]

@zero77, hello and thanks for the report. It seems AdGuard Home can't find any appropriate resolvers for private PTR queries, since it probably listens to 127.0.0.1 and filters it out to avoid recursion. If the assumption is correct, you'd probably want to uncheck the "Use private reverse DNS resolvers" checkbox (set dns.use_private_ptr_resolvers to false in YAML configuration file), since it will result into NXDOMAIN answers for all private PTR queries as well. If this worked for you?

[zero77]

@EugeneOne1
Thanks for the quick response, i have changed use_private_ptr_resolvers to false and i think its working but i will watch it to make sure this has fixed the problem.

Is there a way this could default to false if 127.0.0.1 is being used.

[EugeneOne1]

@zero77, hello again. We've pushed the latest edge build that should automatically disable the PTR resolvers usage along with the appropriate warning message in log. Could you please check it out?

[zero77]

@EugeneOne1
Thanks for your help, i have updated to v0.108.0-a.865+ee014418 but cannot see any changes as i already made the change you suggested.
I also cannot see any warnings with grep adguard /var/log/syslog only [info] but the fix you suggested has worked.

[EugeneOne1]

@zero77, well, in order to meet the message, you have to set the dns.use_private_ptr_resolvers back to true. However, you'd probably want to keep it disabled afterwards, since you don't use it anyway. The message itself should be logged at [info] level with a "WARNING: ..." prefix.

[agross]

Hello @EugeneOne1,

I have this in my config and I want to use these private DNS upstreams despite them running on 127.0.0.1:

  use_private_ptr_resolvers: true
  local_ptr_upstreams:
    - '# Resolve IPv4 PTR using dnsmasq...'
    - '[/in-addr.arpa/]127.0.0.1:53532'
    - '# ...and IPv6 PTR using systemd-resolved which supports NDP to resolve link-local addresses.'
    - '[/ip6.arpa/]127.0.0.1:53531'

The adguard/adguardhome:latest (3bd2fdc8bdc9) and adguard/adguardhome:edge (90ca18c8baca) images still fail with this message.

[EugeneOne1]

@agross, hello. It seems you haven't specified the default (not domain-specific) upstream servers. Since those upstreams handle only the PTR requests for private IP addresses, i.e. only *.in-addr.arpa and *.ip6.arpa, I suppose you may simply remove one of the specifications, e.g.:

local_ptr_upstreams:
  - '# Resolve IPv4 PTR using dnsmasq...'
  - '127.0.0.1:53532'
  - '# ...and IPv6 PTR using systemd-resolved which supports NDP to resolve link-local addresses.'
  - '[/ip6.arpa/]127.0.0.1:53531'

[agross]

@EugeneOne1 Thanks for the prompt response! Yes, removing [/in-addr.arpa/] solves the issues. The latest image now starts up. Thanks!

[EugeneOne1]

@agross, I've actually tried this configuration with several versions, including the one before the commit that caused this problem, and it didn't work. So out of curiosity, has this configuration ever worked? And if it did, do you remember the last such version?

[agross]

@EugeneOne1 Yes, it worked until yesterday when I upgraded the image. The version I used before was using config schema version 27 (or at least it was able to understand it). It's a bit of a guess from yesterday's shell logs, but this is an old version:

adguard/adguardhome@sha256:efe08a321f2328e72e2d173818fb08ce25a2af5fbb94ad80cf4ddb04f79a95cc

Its first lines of the image's output match the log output stored in the system journal from e.g. March 12: AdGuard Home, version v0.107.40

Here's the config for you to try (old schema):

http:
  pprof:
    port: 6060
    enabled: false
  address: 0.0.0.0:30000
  session_ttl: 720h
auth_attempts: 5
block_auth_min: 15
http_proxy: ""
language: ""
theme: auto
dns:
  bind_hosts:
    - 0.0.0.0
  port: 53
  anonymize_client_ip: false
  ratelimit: 0
  ratelimit_whitelist: []
  refuse_any: true
  upstream_dns:
    - '# dnsmasq.'
    - 127.0.0.1:53532
    - '[/ogd.therightstuff.de/]172.16.1.3'
  upstream_dns_file: ""
  bootstrap_dns:
    - 1.1.1.1
    - 1.0.0.1
    - 9.9.9.10
    - 149.112.112.10
    - 2620:fe::10
    - 2620:fe::fe:10
  fallback_dns: []
  all_servers: false
  fastest_addr: false
  fastest_timeout: 1s
  allowed_clients: []
  disallowed_clients: []
  blocked_hosts:
    - version.bind
    - id.server
    - hostname.bind
  trusted_proxies:
    - 127.0.0.0/8
    - ::1/128
  cache_size: 0
  cache_ttl_min: 0
  cache_ttl_max: 0
  cache_optimistic: false
  bogus_nxdomain: []
  aaaa_disabled: false
  enable_dnssec: false
  edns_client_subnet:
    custom_ip: ""
    enabled: false
    use_custom: false
  max_goroutines: 300
  handle_ddr: true
  ipset: []
  ipset_file: ""
  bootstrap_prefer_ipv6: false
  upstream_timeout: 10s
  private_networks: []
  use_private_ptr_resolvers: true
  local_ptr_upstreams:
    - '# Resolve IPv4 PTR using dnsmasq...'
    - '[/in-addr.arpa/]127.0.0.1:53532'
    - '# ...and IPv6 PTR using systemd-resolved which supports NDP to resolve link-local addresses.'
    - '[/ip6.arpa/]127.0.0.1:53531'
  use_dns64: false
  dns64_prefixes: []
  serve_http3: false
  use_http3_upstreams: false
tls:
  enabled: false
  server_name: ""
  force_https: false
  port_https: 443
  port_dns_over_tls: 853
  port_dns_over_quic: 784
  port_dnscrypt: 0
  dnscrypt_config_file: ""
  allow_unencrypted_doh: false
  certificate_chain: ""
  private_key: ""
  certificate_path: ""
  private_key_path: ""
  strict_sni_check: false
querylog:
  ignored: []
  interval: 24h
  size_memory: 1000
  enabled: true
  file_enabled: true
statistics:
  ignored: []
  interval: 2160h
  enabled: true
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://easylist.to/easylistgermany/easylistgermany.txt
    name: EasyList Germany
    id: 1638723473
  - enabled: true
    url: https://easylist.to/easylist/easylist.txt
    name: EasyList
    id: 1638723474
whitelist_filters: []
user_rules:
  - '@@||localhost^$important'
dhcp:
  enabled: false
  interface_name: ""
  local_domain_name: lan
  dhcpv4:
    gateway_ip: ""
    subnet_mask: ""
    range_start: ""
    range_end: ""
    lease_duration: 86400
    icmp_timeout_msec: 1000
    options: []
  dhcpv6:
    range_start: ""
    lease_duration: 86400
    ra_slaac_only: false
    ra_allow_slaac: false
filtering:
  blocking_ipv4: ""
  blocking_ipv6: ""
  blocked_services:
    schedule:
      time_zone: Local
    ids: []
  protection_disabled_until: null
  safe_search:
    enabled: false
    bing: true
    duckduckgo: true
    google: true
    pixabay: true
    yandex: true
    youtube: true
  blocking_mode: nxdomain
  parental_block_host: family-block.dns.adguard.com
  safebrowsing_block_host: standard-block.dns.adguard.com
  rewrites: []
  safebrowsing_cache_size: 1048576
  safesearch_cache_size: 1048576
  parental_cache_size: 1048576
  cache_time: 30
  filters_update_interval: 12
  blocked_response_ttl: 10
  filtering_enabled: true
  parental_enabled: false
  safebrowsing_enabled: false
  protection_enabled: true
clients:
  runtime_sources:
    whois: true
    arp: true
    rdns: true
    dhcp: true
    hosts: false
  persistent: []
log:
  file: ""
  max_backups: 0
  max_size: 100
  max_age: 3
  compress: false
  local_time: false
  verbose: false
os:
  group: ""
  user: ""
  rlimit_nofile: 0
schema_version: 27

$ docker run --rm -v /dir/with/config/above:/opt/adguardhome/conf adguard/adguardhome@sha256:efe08a321f2328e72e2d173818fb08ce25a2af5fbb94ad80cf4ddb04f79a95cc

2024/03/26 08:10:31.657797 [info] AdGuard Home, version v0.107.40
...
2024/03/26 08:10:31.665521 [info] dnsproxy: max goroutines is set to 300
2024/03/26 08:10:31.665526 [info] dnsproxy: creating udp server socket 0.0.0.0:53
...

versus:

$ docker run --rm -v /dir/with/config/above:/opt/adguardhome/conf adguard/adguardhome:latest

2024/03/26 08:11:12.110836 [info] AdGuard Home, version v0.107.46
2024/03/26 08:11:12.111399 [info] Upgrade yaml: 27 to 28
...
2024/03/26 08:11:12.117672 [info] dnsproxy: max goroutines is set to 300
2024/03/26 08:11:12.119139 [error] querylog: closing: flushing log buffer: nothing to write to a file
2024/03/26 08:11:12.119146 [fatal] dnsServer.Prepare: setting up resolvers: creating local resolvers: validating general upstreams: no default upstreams specified

[EugeneOne1]

@agross, thank you for your thorough answer, this is really helpful. We'll investigate it since the behavior isn't really intended and may be caused by another bug.