Strange behavior with unbound

[scream]

Hi

I noticed a strange behavior with unbound when I checked my upstream DNS logs.

Unbound tries to resolve names like:

Code: [Select]

host1.localdomain.tld.localdomain.tld
or

Code: [Select]

google.com.localdoman.tld
So... I don't get why this happens.
I already tcpdumped on some of my servers to check if the server does such reqeusts but they look all fine.
So for me it looks like unbound does add the "localdomain.tld" to a FQDN.

Any hint is likly welcome!


Edit:
I guess it depends as I added the following lines to unbound custom config to use DoT service:

Code: [Select]

forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: x.y.z.a@853#dnsserver.domain.tld
For me it is still unclear why this happens.
Why unbound forward "host1.localdomain.tld.localdomain.tld" to the upstream DNS even there is a local entry for "host1.localdomain.tld"

[Fright]

hi
just add closing "." when checking via nslookup )

[scream]

hi
just add closing "." when checking via nslookup )

The problem dosn't occour just on "nslookup" ... I can see more than 1k of such DNS requests from different hosts.
And this does only happen with unbound. If I test by just using dnscrypt-proxy is doesn't happen anymore. So unbound adds the additional (second) domain.tld.

So it is not the DNS client which does request this... as when dnscrypt-proxy is running on port 53 you can see that this never happens.

When I use unbound and forward to dnscrypt-proxy I can see that porblem again with host1.domain.tld.domain.tld

[Fright]

hi
still have not found evidence that the unbound itself can do this.
is dhcpd enabled (domain\domain search list options?)?
can you capture packets on the internal interface to completely eliminate the possibility of adding a local suffix on the client?

[Patrick M. Hausen]

@Fright
Correct. A recursive nameserver does not ad search domains on behalf of the client. The local resolver library does that.

@scream:
Do you have a domain name and/or more search domains in your DHCP settings and possibly an FQDN configured for your individual hosts (in DHCP)?

[scream]

Okay.... I now dumped around 30 mins of DNS traffic on 3 different VLANs and looks like you're right.
I can see that some clients resolving such sh**:

Code: [Select]

local-server1.domain.tld.domain.tld
www.googleapis.com.domain.tld

Yes I defined a Domain for DHCP clients and a search list. And also a static one in resolv.conf when not DHCP is used.

[Fright]

Yes I defined a Domain for DHCP clients and a search list
this is the answer why such requests arise

so that requests to addresses for these domains are not forwarded imho you need to make local-zones with the "static" type for this domains (looks like there is no gui param for making this for domains from DHCP "domain search list" option. for System Domain it generates local-zone with "local zone type" from unbound general settings. ie at least for the system domain, you can set the zone type to 'static' in Services: Unbound DNS: General)

[scream]

so that requests to addresses for these domains are not forwarded imho you need to make local-zones with the "static" type for this domains (looks like there is no gui param for making this for domains from DHCP "domain search list" option. for System Domain it generates local-zone with "local zone type" from unbound general settings. ie at least for the system domain, you can set the zone type to 'static' in Services: Unbound DNS: General)

I've already:

Code: [Select]

local-zone: "domain.tld" static
local-zone: "otherdomain.tld" static
local-zone: "use-application-dns.net" always_nxdomain

But this doesn't help and I still see that requests are made to things like

Code: [Select]

googleapis.com.domain.tld

This is why I'm confused as I thought that set it a local-zone = static should not forward it and only get a result when local-data is configured.

I really don't know what happens there :/

[Fright]

I've already
sorry, where did you insert these options?

i checked:
create file aa.conf in /var/unbound/etc
add

Code: [Select]

local-zone: "github.com" staticto aa.conf
enable log level 5
restart unbound
nslookup for google.com.github.com.
received nxdomain and got the following in the log:
unbound[25250]   [25250:0] debug: using localzone github.com. static   
unbound[25250]   [25250:0] info: 172.17.1.18 google.com.github.com. AAAA IN   
unbound[25250]   [25250:1] debug: using localzone github.com. static   
unbound[25250]   [25250:1] info: 172.17.1.18 google.com.github.com. A IN   

[scream]

I put it in the "Custom options" field in the WebGUI.

But may it would be easier to explain what I want to realize and may we will find another way.

I've a TLD (e.g. my-domain.tld). This domain is used in the internet (e.g. public.my-domain.tld).

I use the subdomains internal.my-domain.tld and dmz.my-domain.tld for local systems (behind opnsense).

So my idea was to put it as local-zone in the "Custom options" field like that:

Code: [Select]

local-zone: "internal.my-domain.tld" static
local-zone: "dmz.my-domain.tld" static

Then I added Host Overrides for each server in the Overrides section of unbound.

All of this is working fine. I can resolve the names local by using unbound on opnsense and I can't resolve the local names when using the internet DNS. (which is expected). -> OK

Beside this I've configured unbound to forward all to a DoT DNS server.
On this DoT-DNS server I can see in the logs, that unbound tries to resolve names for internal devices like:

Code: [Select]

server1.dmz.my-domain.tld.internal.my-domain.tld
server1.internal.my-domain.tld.my-domain.tld
server1.internal.my-domain.tld.dmz.my-domain.tld
google.com.my-domain.tld

And now I want to find out why unbound tries to resolve such strange names?
Specially when server1.dmz.my-domain.tld is already a valid one and unbound had local data (host override) for?

In the end I just want that everything with "internal.my-domain.tld" and "dmz.my-domain.tld" NEVER is forwarded to an internet DNS server.

[Fright]

can you please check again what kind of requests the unbound forwards  exactly?
for example, the request for

Code: [Select]

server1.internal.my-domain.tld.my-domain.tldshould be forwarded. unbound does not own "tld.my-domain.tld" zone

a more radical way is also possible if there are few records for the domain on the external servers. in this case, you can take the entire "my-domain.tld" domain to static local-zone and add the required records to the host override

[scream]

can you please check again what kind of requests the unbound forwards  exactly?
for example, the request for

Code: [Select]

server1.internal.my-domain.tld.my-domain.tldshould be forwarded. unbound does not own "tld.my-domain.tld" zone

I can do... but:

tld.my-domain.tld is not a local-zone, this is correct. But why it searchs for this? "server1.internal.my-domain.tld is local-zone and there is local-data for this host.

But one example (there are multiple):

Code: [Select]

real hostname: accesspoint1.internal.my-domain.tld
dns request on public resolver: accesspoint1.internal.my-domain.tld.my-domain.tld
The client who has made this DNS query is my monitoring system where hostname is specified as "accesspoint1.internal.my-domain.tld"

a more radical way is also possible if there are few records for the domain on the external servers. in this case, you can take the entire "my-domain.tld" domain to static local-zone and add the required records to the host override

This is not possible as some of them are dynamic and are changes by cloud LB automaticly. In this case I had to change them on opnsense every time it changes in the cloud.

[Fright]

dns request on public resolver: accesspoint1.internal.my-domain.tld.my-domain.tld
client appends "my-domain.tld" (since you add "my-domain.tld" to DHCP domain\domain search list) to the "server1.internal.my-domain.tld" name, unbound receives this request, neither "my-domain.tld" nor "tld.my-domain.tld" is static local-zone. so unbound forwards this request.
in next request client will ask for "accesspoint1.internal.my-domain.tld" and everything will go as expected