local_domain_name: when set lost rewrites: from that domain

[bcookatpcsd]

local defined dns record:

• domain: option252.domain
  answer: 10.20.0.30

> drill option252.domain @10.20.0.53
> ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 27792
> ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
> ;; QUESTION SECTION:
> ;; option252.domain.	IN	A
> 
> ;; ANSWER SECTION:
> 
> ;; AUTHORITY SECTION:
> option252.domain.	10	IN	SOA	fake-for-negative-caching.adguard.com. hostmaster.option252.domain. 100500 1800 900 604800 86400
> 
> ;; ADDITIONAL SECTION:
> 
> ;; Query time: 233 msec
> ;; SERVER: 10.20.0.53
> ;; WHEN: Mon Apr 19 12:35:52 2021
> ;; MSG SIZE  rcvd: 132

Also:

local_ptr_upstream not filled in.

• '[/20.10.in-addr.arpa/]172.16.254.241:53'
• '[/120.10.in-addr.arpa/]172.16.254.241:53'
• '[/16.172.in-addr.arpa/]172.16.254.241:53'

these entries did not get me PTR entries with local_domain_name filled in. When I changed local_domain_name: back to lan and restarted.. I had static entries and ptr working again..

I also changed:

log_compress: true
log_localtime: true

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vrutkovs]

Reproducible in v0.106.3

[shawly]

I also got this issue with v0.106.3

As soon as I add lan.mydomain.net as local_domain_name I cannot resolve any local domains anymore.

[ainar-g]

@vrutkovs, @shawly, what upstreams did you put into the “Private reverse DNS servers” field? Requests for names within local_domain_name are redirected there.

[bcookatpcsd]

Sorry to somewhat hijack this..

How does AGH know which domains to that are private..

What is the difference between the two sections?

and within my config file:

local_domain_name: lan
 resolve_clients: true
 use_private_ptr_resolvers: true
 local_ptr_upstreams:
 - '[/20.10.in-addr.arpa/]172.16.254.241'
 - '[/16.172.in-addr.arpa/]172.16.254.241'
 - '[/120.10.in-addr.arpa/]172.16.254.241'

AdGuard Home, version v0.107.0-b.11

ptr resolution works as expected.

But I forget the reasoning that things went in the bottom and not the top section.. to avoid queries to AG services? For the local recursion/speed?

Is everything in the top section sent to AG services for 'checking', if the choice is made to do so?

github dnsproxy has no other documentation about the local_domain_section.. so assuming that is a AGH 'thing' and not a dnsproxy setting..

Thanks in advance..

[EugeneOne1]

@bcookatpcsd, AdGuard Home uses registries from RFC-6303 to consider the address being private. The upstream servers from Private reverse DNS servers field are used only to resolve the PTR requests for these addresses.

local_domain_name is only used to resolve the hostnames leased by AdGuard Home's DHCP server. In fact these requests aren't sent to upstream at all.

Since the screenshot tells that default local resolvers couldn't be determined, I can assume, that the problem may be caused by this domain-specific configuration for Private reverse DNS servers. Could you please try to leave it with only a single upstream 172.16.254.241.

[agross]

@vrutkovs, @shawly, what upstreams did you put into the “Private reverse DNS servers” field?

In my case I use the same single IP that I use for my "Upstream DNS Server".

Requests for names within local_domain_name are redirected there.

Why should an A query redirect to a reverse DNS server? Also in my case I'm trying to resolve DNS rewrites. As soon as a rewrite entry matches the local_domain_name the rewrite seems to be ignored. One can test that even with the default local_domain_name: lan. Add a new rewrite for foo.lan pointing to 1.2.3.4 and try to resolve than name:

$ dig foo.lan

; <<>> DiG 9.10.6 <<>> foo.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21899
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;foo.lan.			IN	A

;; AUTHORITY SECTION:
foo.lan.		10	IN	SOA	fake-for-negative-caching.adguard.com. hostmaster.foo.lan. 100500 1800 900 604800 86400

;; Query time: 50 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Mon Oct 11 08:56:22 CEST 2021
;; MSG SIZE  rcvd: 123

[EugeneOne1]

@agross, as you said:

In my case I use the same single IP that I use for my "Upstream DNS Server".

I afraid, in this case all the requests from your local devices for local addresses are sent to the specified upstream so if it's an external server (not in your local network) then some sensible information may be exposed (See #2704).

Why should an A query redirect to a reverse DNS server?

My colleague answered not quite accurate. These requests are intended to be resolved within built-in DHCP server as I mentioned before. Since domains with local_domain_name are handled before applying any filtering, those are also ignored by rewrites if weren't resolved (NXDOMAIN). I suppose in your case the DHCP server is disabled or has no clients with name foo.

[agross]

Hello @EugeneOne1 ,

I afraid, in this case all the requests from your local devices for local addresses are sent to the specified upstream

The question is what is considered to be a "local" address. As I run DHCP I would expect that all DHCP leases are considered to be local. But these names are not resolved when I only pass the hostname without the default lan suffix.

I suppose in your case the DHCP server is disabled or has no clients with name foo.

The DHCP server has leases for the addresses in question. 192.168.0.2 is my AdGuard Home server.

$ dig poco-x3-alex

; <<>> DiG 9.10.6 <<>> poco-x3-alex
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28092
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;poco-x3-alex.			IN	A

;; Query time: 308 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Mon Oct 11 15:06:04 CEST 2021
;; MSG SIZE  rcvd: 41

$ dig poco-x3-alex.lan

; <<>> DiG 9.10.6 <<>> poco-x3-alex.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18636
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;poco-x3-alex.lan.		IN	A

;; ANSWER SECTION:
poco-x3-alex.lan.	10	IN	A	192.168.0.12

;; Query time: 45 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Mon Oct 11 15:06:07 CEST 2021
;; MSG SIZE  rcvd: 50

It seems like unqualified hostnames are always forwarded to the upstream resolver. Another example, based on another screenshot (not sure which setting matters):

$ dig nwa210ax

; <<>> DiG 9.10.6 <<>> nwa210ax
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19074
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nwa210ax.			IN	A

;; Query time: 45 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Mon Oct 11 15:16:41 CEST 2021
;; MSG SIZE  rcvd: 37

$ dig nwa210ax.lan

; <<>> DiG 9.10.6 <<>> nwa210ax.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59052
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;nwa210ax.lan.			IN	A

;; ANSWER SECTION:
nwa210ax.lan.		10	IN	A	192.168.0.13

;; Query time: 44 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Mon Oct 11 15:16:44 CEST 2021
;; MSG SIZE  rcvd: 46

[bcookatpcsd]

in the config file:

  upstream_dns:
  - sdns://AgYAAAAAAAAACDkuOS45LjEwICoV9dastufAkBreTrvHQ7LM1IkDK0bhZC8Gk2gwASWKFGRuczEwLnF1YWQ5Lm5ldDo1MDUzCi9kbnMtcXVlcnk
  - '# quad9-doh-ip4-port5053-nofilter-pri'
  - sdns://AQcAAAAAAAAAEjQ1LjYzLjExMC4xODc6ODQ0MyCcjeRhPcJTsKhZ8iViALPd39CussG6SnprFT9z_1f03x0yLmRuc2NyeXB0LWNlcnQucGxhbjktbnMyLmNvbQ
  - '# dnscrypt cryptostorm plan9-ns2'
  - sdns://BAYAAAAAAAAAAAAeZG5zLXVuZmlsdGVyZWQuYWRndWFyZC5jb206Nzg0
  - '# adguard quic 784'
  - sdns://AgcAAAAAAAAADjE3Mi42Ny4xMzQuMTU3AA1kb2guY3J5cHRvLnN4Ci9kbnMtcXVlcnk
  - '# doh-crypto-sx'
  - '[/vlan10.dns/]192.168.10.105:531'
  - '[/vlan20.dns/]192.168.10.105:531'
  - '[/vlan172.dns/]192.168.10.105:531'

  bootstrap_dns:
  - 45.90.28.0

  local_domain_name: lan
  resolve_clients: true
  use_private_ptr_resolvers: true
  local_ptr_upstreams:
  - '[/168.192.in-addr.arpa/]192.168.10.105:531'

Not sure if this helps..

[EugeneOne1]

@agross

The question is what is considered to be a "local" address.

As I also mentioned, the address is considered "local" if it's contained in one of RFC-6303's registries. To distinct those from DHCP's ones let's call it "private".

It seems like unqualified hostnames are always forwarded to the upstream resolver.

Forwarding unqualified domains to the upstream is an expected behaviour since there is no simple way to determine if the client meant the DHCP-leased domain name or some global one. The distinction between the two is the main purpose of local_domain_name setting.

However, the screenshot of your Clients section tells that the address for poco-x3-alex wasn't actually leased by AGH's DHCP server. What version of AGH are you using? This may be a consequence of invalid client sources priority which is already fixed in latest edge and beta builds.

[bcookatpcsd]

my dhcp server is dnsmasq, at 192.168.10.105 and dns for that is running on 531..

[EugeneOne1]

@bcookatpcsd, as far as I can see all the clients are resolved with reverse DNS. Isn't that is what you wanted to achieve?

And again, all the addresses from 192.168/16 are considered "private", i.e. are resolved via private resolvers. So you may leave the local_ptr_upstreams with the only 192.168.10.105:531 entry without any modifiers:

local_ptr_upstreams:
- '192.168.10.105:531'

Please note that local_domain_name is only for DHCP-leased domains. It has nothing to do with private resolvers.

[agross]

@EugeneOne1

As I also mentioned, the address is considered "local" if it's contained in one of RFC-6303's registries. To distinct those from DHCP's ones let's call it "private".

OK, so my DHCP addresses are in the 192.168.0.0/24 subnet. Which should make them "private" according to RFC-6306. Did I understand that correctly?

However, the screenshot of your Clients section tells that the address for poco-x3-alex wasn't actually leased by AGH's DHCP server.

poco-x3-alex is a static DHCP lease, but from my perspective that should not matter.

What version of AGH are you using?

I'm using v0.106.3 from docker hub. Likely not one of the builds you mention as latest is 4 months old. After upgrading to edge poco-x3-alex is now listed as DHCP and I can resolve it by its sole hostname.

[agross]

After upgrading to edge poco-x3-alex is now listed as DHCP and I can resolve it by its sole hostname.

Correction, I can't. What I am basically looking for is something like dnsmasq's expand-hosts in conjunction with domain, e.g.

# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.
expand-hosts

# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
#     as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
#    domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"
domain=home.therightstuff.de, 172.16.0.0/24, local

Does AdGuard support something like this?

[EugeneOne1]

@agross

OK, so my DHCP addresses are in the 192.168.0.0/24 subnet. Which should make them "private" according to RFC-6306. Did I understand that correctly?

These addresses are considered "private" by RFC-6303, but not in context of the conversation. When you request the address of hostnames leased by AGH's DHCP server, you actually send a A/AAAA request. And the only things are checked against "private" registries are the requestor's address and the requested address (only in case of PTR).

Does AdGuard support something like this?

AGH parses the default hosts file of the system. You may simply add there the entries you need.

[bcookatpcsd]

I have no problem with my AGH.. I was showing working examples of what does work.. In hopes of helping figure out the problem.

Not sure if his dnsmasq is setup correctly.. /var/lib/misc/dnsmasq.leases (standard location) or man dnsmasq FILES..

Or the dhcp-leasefile directive..

[EugeneOne1]

@bcookatpcsd
To be fair, I'm not quite sure I've got the issue correctly. To request the AGH's DHCP-leased addresses by hostname use the hostname with local_domain_name appended. To request the hostnames of those use the in-addr.arpa hostname of the address.

Could you please clarify what's exactly goes wrong?

[shawly]

@vrutkovs, @shawly, what upstreams did you put into the “Private reverse DNS servers” field? Requests for names within local_domain_name are redirected there.

I tried putting AGH as upstream and I tried it without any private reverse DNS servers as well.
My AGH instance had DHCP enabled and I had no other DHCP servers in the network. As soon as I set the local_domain_name to my custom domain, all my custom DNS entries for that domain could not be resolved anymore.

E.g. when DHCP is enabled device A registers as devicea.mycustomdomain.tld when local_domain_name is set to mycustomdomain.tld and reverse lookup of the IP as well as lookup of devicea.mycustomdomain.tld works as expected.
But if I additionaly add a custom DNS A record with alias.mycustomdomain.tld that points to the IP of device A or a CNAME record that points do devicea.mycustomdomain.tld those records simply won't resolve and return NXDOMAIN.

[Nitrouze]

E.g. when DHCP is enabled device A registers as devicea.mycustomdomain.tld when local_domain_name is set to mycustomdomain.tld and reverse lookup of the IP as well as lookup of devicea.mycustomdomain.tld works as expected. But if I additionaly add a custom DNS A record with alias.mycustomdomain.tld that points to the IP of device A or a CNAME record that points do devicea.mycustomdomain.tld those records simply won't resolve and return NXDOMAIN.

I have the exact same problem, did anyboby find a solution for this ?
Thx

[shawly]

No solution, I switched back to PiHole.

[agross]

I use dnsmasq in front of AdGuard. Custom DNS is much more versatile with it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.