Unbound: Host Override ignoring "domain" portion for unqualified queries?

johnpoz

well what is the search suffix on your machine? if its foobar.xyz then yeah doing a query for host name with your search suffix added would return your override.

But dig auto will add the trailing . on a specific name only query. While nslookup will not.

nslookup
Default Server: pfSense.local.lan
Address: 192.168.9.253

aaahost
Server: pfSense.local.lan
Address: 192.168.9.253

*** pfSense.local.lan can't find aaahost: Non-existent domain
> aaahost.
Server: pfSense.local.lan
Address: 192.168.9.253

Name: aaahost
Address: 1.2.3.4

notice when I do it on dig the actual question asked is aaahost.

dig aaahost

; <<>> DiG 9.10.4-P1 <<>> aaahost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19113
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
aaahost. 3600 IN A 1.2.3.4

;; Query time: 0 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Thu Jul 14 12:11:58 Central Daylight Time 2016
;; MSG SIZE rcvd: 52

This is WAD (works as designed) from my understanding. Is this causing you some sort of issue, or just curious to why? I will have to look to unbound settings, there might be something to change this behavior.

edit: ok found a work around for this. This must be how the pfsense gui is putting this info into the unbound config. If you do not want the host name only to resolve then vs using the gui to add the override you can add the specific fqdn using local data in the option box

server:
local-data: "aaahost.foobar.xyz. IN A 1.2.3.4"

dig aaahost.

; <<>> DiG 9.10.4-P1 <<>> aaahost.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26979
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
. 3548 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2016071400 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Thu Jul 14 12:25:04 Central Daylight Time 2016
;; MSG SIZE rcvd: 111

luckman212

@johnpoz:

well what is the search suffix on your machine? if its foobar.xyz then yeah doing a query for host name with your search suffix added would return your override.

Yes I do understand that. The search suffix on my machine is "baz" (comes from System > General / DHCP as noted above).

@johnpoz:

Is this causing you some sort of issue, or just curious to why? I will have to look to unbound settings, there might be something to change this behavior.

Yes it is causing an issue— consider the following:

Let's say I have a local server named pve01. And also a the Host Override pve01.foobar.xyz pointing to a different IP.

If I want to connect to the LAN pve01 server, it returns BOTH IPs - see screenshot:

Not to mention it just seems wrong to me that it would work like this. Trying to think of a case where this would be the desired behavior??

johnpoz

what would be the fqdn of your pve01 box… Why would you ever have just a host name to find something? You should always use fqdn. So ok you have server local called pve01.something.tld and then your override of pve01.foobar.xyz so you should be fine.

But I agree with you it could be problematic.. I agree with you all queries should always be fully qualified.. if you have record for host.domain.tld a query for host. should not return that record.

Have to look into redmine and see if anyone has opened a ticket about this. But either way the work around I posted works.

as to your search suffix being single label - not a fan of that to be honest, but sure if that is what you want.. I personally think its bad habit and practice.

I stated it most likely WAD designed is because there have been previous posts where users specifically desired host name to respond. But I don't understand the use case of that either. Other then lazy users not wanting to type out fully qualified or proper use of search suffixes when and where they work, etc.

luckman212

@johnpoz:

what would be the fqdn of your pve01 box…

pve01.baz in this case

@johnpoz:

Why would you ever have just a host name to find something? You should always use fqdn.

I agree but there are some cases where this can't be controlled (someone else's software) or other reasons why you might want it (maybe you want to make a bookmark for http://pve01 that works from 2 different search domains - home & work…)

@johnpoz:

So ok you have server local called pve01.something.tld and then your override of pve01.foobar.xyz so you should be fine.

Yes as long as the full FQDN is used, the correct values are returned

@johnpoz:

Have to look into redmine and see if anyone has opened a ticket about this. But either way the work around I posted works.

Thank you- actually I did stumble onto that same workaround, I was just posting here so that I could get feedback

@johnpoz:

as to your search suffix being single label - not a fan of that to be honest, but sure if that is what you want.. I personally think its bad habit and practice.

agree w/ you 100% - actually these examples are not my real info - real suffix is more like foo.bar but for the example it didn't matter.

cmb

Prior to 2.3.2, the non-fully qualified hostname was put in the hosts file and in Unbound's config, without any consideration for the domain. So if you had abc.example.com and abc.example.net pointing to two diff IPs, doing a lookup on just "abc" would result in a round-robin reply with both IPs.

In 2.3.2+, the non-FQDN hostnames are excluded entirely from hosts (for the host itself and dnsmasq) and Unbound's config, so that won't happen.

luckman212

Ah, ok – I'll test w/ 2.3.2 snapshot

thanks Cmb ;)

johnpoz

So it was WAD then ;) glad to see it being changed.. Looks like some good stuff coming in 2.3.2.. Might have to move to it early as well ;)

luckman212

@cmb:

In 2.3.2+, the non-FQDN hostnames are excluded entirely from hosts (for the host itself and dnsmasq) and Unbound's config, so that won't happen.

I upgraded to 2.3.2.a.20160714.1554, deleted my Host Override and then re-added it. But I'm still seeing the same result as before. When I query for the unqualified host (pve01) I get back both IPs from Unbound. Do I need to change some other settings somewhere to see the new behavior?

johnpoz

check your host file, guess is left those in there since you did an upgrade.

luckman212

I checked /etc/hosts I see that there are in fact 2 entries for the "pve01" unqualified hostname

1.2.3.4          pve01.foobar.xyz pve01
192.168.20.31    pve01.baz pve01

Like I said, I deleted the Host Override, confirmed that it was completely gone from /etc/hosts and then re-added it. But again it puts back the line:

1.2.3.4          pve01.foobar.xyz pve01

Maybe I'm not on the right snapshot??

cmb

Oh, misremembered where I pushed that. It's in 2.4 only, as 2.3.2 has minimal time for baking in snapshots and I'm thinking that's likely going to trigger some regression in some edge case.

You can apply the diffs from the two commits on this ticket.
https://redmine.pfsense.org/issues/6064

https://redmine.pfsense.org/projects/pfsense/repository/revisions/f1db82aca3f260921ce0c5f71ff3a93149ffebc0/diff/src/etc/inc/unbound.inc
https://redmine.pfsense.org/projects/pfsense/repository/revisions/0fa68840504f6866901e0d02819d43a3ce9f9578/diff/src/etc/inc/system.inc

luckman212

Ok thanks again.

Just to clarify, the correct way to do what you are suggesting:

Install System_Patches package
create 2 patches, reference the following 2 commits:

f1db82aca3f260921ce0c5f71ff3a93149ffebc0
0fa68840504f6866901e0d02819d43a3ce9f9578

```3) Apply

I did this and it seemed to work….. just making sure

also......How can we begin testing 2.4?

cmb

Yes, that's correct.

We'll have 2.4 snapshots out before too long, then we'll have a board up here for testers.

luckman212

Just wanted to report back, been running that patch with no ill effects for just about a week now. Has been working fine.

edit: Been well over a month now, running those patches and they are not causing any problems at all for me. Not sure how far off 2.4 is but it would definitely be nice to see these committed for 2.3.3.