DNS Resolver (unbound) not updating ?

johnpoz

Do you have views setup on your AD setup, or conditional forwarders, etc.

Without more info to your setup of your dns in AD, not sure.. What version of windows you running 2k12, 2k16, 2003? etc.. Over the years they have made changes to how DNS works in windows for features... Your not still using wins are you?

Are you syncing DNS across multiple servers in your AD.. I assume you have it directory-integrated, etc.

to be used as the primary DNS ... ?

Not a fan when users state such a thing... While you can point clients to more than 1 NS.. you have to be SURE!!!! that these NS are going to resolve/forward and return the same info..

For example - you can not point a client to your local AD dns, while also listing say 8.8.8.8 be it 2nd NS or not.. You will have a bad day if you setup this way.. Since you can never be sure where a client will ask if there is more than 1 NS listed. So sure you could point to multiple AD dns that all return the same info.. But you can not point a client to say

NS1 10.x.x.x
NS2 8.8.8.8

Without running into problems at some point..

Lumberjack

The dc used here (10.100.102.11) are 2012 R2 std. Not wins, no. There exist "backup" dc's. It's a single site domain, no forest's or other "advanced" stuff used.

I have often used multiple DNS's in DHCP, but I see your point.

However, to clearify a bit (Note: i masked the real FQDN's with x's in the snippet below);

When on a windows client in the "outbound subnet", the DNS settings are as follows;

[D:\Source\Code\phy]ipconfig /all

Windows IP Configuration
   ...
   DNS Servers . . . . . . . . . . . : 10.100.0.1
                                       10.100.102.11
   ...

The 10.100.0.1 is the pfSense, DNS resolver enabled here (to enable som "host overrides"). So we ask to resolve;

[D:\Source\Code\phy]nslookup client5.xxx.xx
Server:  pfSense.xxx.xx
Address:  10.100.0.1

Name:    client5.xxx.xx
Address:  10.100.12.8

Now, earlier we established that outbound on pfSense are actually using 10.100.102.11

The following name servers are used for lookup of client5.xxx.xx.
The noprime stub servers are used:
Delegation with 0 names, of which 0 can be examined to query further addresses.
It provides 1 IP addresses.
10.100.102.11   	NoDNSSEC rto 12 msec, ttl 366, ping 0 var 3 rtt 50, tA 0, tAAAA 0, tother 0, EDNS 0 probed.

But when we resolve through 10.100.102.11 directly;

[D:\Source\Code\phy]nslookup client5.xxx.xx 10.100.102.11
Server:  pdc03.xxx.xx
Address:  10.100.102.11

Name:    client5.xxx.xx
Address:  10.100.105.79

We get another IP. This is the correct one.

I did a quick check on the DNS setup on 10.100.102.11: exporting everything to a .txt file and the a search, but 10.100.12.8 was not found anywhere.

johnpoz

@Lumberjack said in DNS Resolver (unbound) not updating ?:

Windows IP Configuration
...
DNS Servers . . . . . . . . . . . : 10.100.0.1
10.100.102.11
...

That is going to be problematic..

Your clients should point to AD if they are members of the AD or need to resolve stuff in AD... You would then forward from your AD to pfsense if you want AD to resolve stuff in pfsense overrides... But why would you not just put the overrides in AD in the first place?

Where are you doing that direct query from? Same subnet as pfsense does it query to your AD?

Just turn on logging in unbound and you can see exactly where your answer coming from..

server:
log-queries: yes
log-replies: yes

Put that in the custom options box on unbound setup..

Then set logging to level 3 or higher

Then query pfsense for this client and you can see exactly where it comes from... So I have a domain override setup for testing to windows dns... for home.lan 192.168.2.220

So when I query pfsense for host.home.lan it goes and asks the windows dns.. You can see exactly what unbound is doing with logging turned on.

Mar 21 10:30:23 	unbound 	6448:1 	info: 192.168.9.100 host.home.lan. A IN NOERROR 0.759713 0 58
Mar 21 10:30:23 	unbound 	6448:1 	info: query response was ANSWER
Mar 21 10:30:23 	unbound 	6448:1 	info: reply from <home.lan.> 192.168.2.220#53
Mar 21 10:30:23 	unbound 	6448:1 	info: response for host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	info: iterator operate: query host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	debug: sending to target: <home.lan.> 192.168.2.220#53
Mar 21 10:30:23 	unbound 	6448:1 	info: sending query: host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	info: processQueryTargets: host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	info: iterator operate: query host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	debug: sending to target: <home.lan.> 192.168.2.220#53
Mar 21 10:30:23 	unbound 	6448:1 	info: sending query: host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	info: processQueryTargets: host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	info: resolving host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	info: validator operate: query host.home.lan. A IN
Mar 21 10:30:23 	unbound 	6448:1 	info: 192.168.9.100 host.home.lan. A IN

You can see my client from 192.168.9.100 ask.. Unbound goes and ask 192.168.2.220 and gets answer

You see what my client gets back.

$ dig @192.168.9.253 host.home.lan

; <<>> DiG 9.12.3-P1 <<>> @192.168.9.253 host.home.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12831
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
host.home.lan.          3600    IN      A       10.10.10.10

;; Query time: 760 msec
;; SERVER: 192.168.9.253#53(192.168.9.253)
;; WHEN: Thu Mar 21 10:30:23 Central Daylight Time 2019
;; MSG SIZE  rcvd: 58

When I ask unbound where it would lookup host.home.lan I get

[2.4.4-RELEASE][admin@sg4860.local.lan]/: /usr/local/sbin/unbound-control -c /var/unbound/unbound.conf lookup host.home.lan
The following name servers are used for lookup of host.home.lan.
forwarding request:
Delegation with 0 names, of which 0 can be examined to query further addresses.
It provides 1 IP addresses.
192.168.2.220           rto 284 msec, ttl 558, ping 0 var 71 rtt 284, tA 0, tAAAA 0, tother 0, EDNS 0 probed.
[2.4.4-RELEASE][admin@sg4860.local.lan]/:

Why when you did for your client you see noprime stub? Please post your unbound config.. Do you have unbound set as stub? vs default transparent You cearly have something more than the gui configurations for unbound going on when it says your using stub zone and not prime.

You are not just forwarding to your AD to lookup specific domain... You or it would say forwarding like mine above when setup domain override to go ask windows dns at 192.168.2.220 for home.lan

Lumberjack

Detected that the site currently is running pfsense 2.3-RELEASE (amd64), FreeBSD 10.3-RELEASE. There is no 'log_replies' unbound option in that freebsd version.

I have scheduled a upgrade. Reporting back after that.

And I detected that unbound is set with "domain override" of the domain (eg. xxx.xx of the client5.xxx.xx). This possibly explains missing calls to prime zone's.

johnpoz

2.3?? Dude that is no longer supported, end of life... You need to upgrade to current..

Let us know after the upgrade.. But its still asking your AD for that..

What version of unbound is it running btw?

Lumberjack

Ok, pf on 2.4.4 now.

I believe I have found source of the the problem. it's this:
https://forum.netgate.com/topic/135409/unbound-dhcp-registration-checkbox-bug

First, I enabled the unbound log (as suggested) an this was the result:

Mar 23 17:44:16 unbound 70805:7 info: 10.100.12.21 client5.xxx.xx. AAAA IN NOERROR 0.000000 1 31 
Mar 23 17:44:16 unbound 70805:7 info: 10.100.12.21 client5.xxx.xx. AAAA IN 
Mar 23 17:44:16 unbound 70805:7 info: 10.100.12.21 client5.xxx.xx. A IN NOERROR 0.000000 1 47 
Mar 23 17:44:16 unbound 70805:7 info: 10.100.12.21 client5.xxx.xx. A IN 
Mar 23 17:44:16 unbound 70805:7 info: 10.100.12.21 1.0.100.10.in-addr.arpa. PTR IN NOERROR 0.000000 1 69 
Mar 23 17:44:16 unbound 70805:7 info: 10.100.12.21 1.0.100.10.in-addr.arpa. PTR IN

That's all. No contact with AD DNS.

So, after some thinkering, i did a cat of the unbound config and found this ;

...
# dhcp lease entries
include: /var/unbound/dhcpleases_entries.conf
...

...whut ?! thats not even enabled?

Then I did a cat on dhcpleases_entries.conf and, yes, i found client5.xxx.xx listed.
...along with approx other 10 names registered, where only 2 still exists today.

Somebody has probably, a long time ago, enabled/checked "DHCP Registration" in the pf GUI. Then unchecked it again a short time after enabling it. But the names collected got stuck in unbound. Not good.

Should I just truncate the dhcpleases_entries.conf or do there exist a more proper way to get rid of it ?

johnpoz

Just delete all the entries in there should be fine.

Lumberjack

Done. It worked, the correct IP are returned now.

One remark;

Something for the devs to consider, This;

usr/local/sbin/unbound-control -c /var/unbound/unbound.conf lookup client5.domain.tld

... should really give some kind of indication that the name in question do exist in a local table.

Grimson

@Lumberjack said in DNS Resolver (unbound) not updating ?:

Something for the devs to consider, This;

usr/local/sbin/unbound-control -c /var/unbound/unbound.conf lookup client5.domain.tld

... should really give some kind of indication that the name in question do exist in a local table.

Talk to the unbound devs then: https://nlnetlabs.nl

Gertjan

@Lumberjack said in DNS Resolver (unbound) not updating ?:

...whut ?! thats not even enabled?

Hummm. This rings a bell to me.
An issue that was solved a couple of updates ago ... emptying the dhcp leases file when dhcpleases process is shut down.

You 'missed' that upgrade I guess ^^

luckman212

This bug is still present in 2.4.4-p3 (and possibly 2.4.5-p1, 2.5.0) and was frustrating to track down today.

Seems like the problem has 2 potential fixes:

make sure the contents of /var/unbound/dhcpleases_entries.conf is 100% cleared when the "Register DHCP leases in the DNS Resolver" checkbox feature is disabled.

or

when said checkbox is cleared, comment out the include: /var/unbound/dhcpleases_entries.conf line in /var/unbound/unbound.conf

I feel like #2 is the better fix, since that way DHCP leases would resolve properly if somone toggles the box off & then back on by mistake.