bandwidthd and name resolution

johnpoz

@hspindel said in bandwidthd and name resolution:

to the list of DNS Servers.

Yeah that is where you have a problem - when you have more than 1 NS, you can not be sure which NS will be used.. You need to have unbound set with a domain override so it knows which specific NS to ask when say looking up something in the 192.168.x.x range, or when it wants to lookup something in the sci1.com domain..

if pfsense happens to ask say googlendns, its not going to know 12.1.1.192.in-addr.arpa is hex64.sci1.com

hspindel

@johnpoz
Thank you for the reply but I'm not sure that's the right track.

pfSense is reliably using my local DNS when I try a ping diagnostic. ping hex64.sci1.com always succeeds. If your suggestion were correct, I think it would fail sometimes.

I did try setting a domain override for sci1.com in the DNS resolver and it didn't help.

I also tried a domain override of 1.1.192.in-addr,arpa and it didn't help either.

johnpoz

@hspindel said in bandwidthd and name resolution:

I think it would fail sometimes.

How long does it have it cached.. Do you have host overrides setup? That should return your PTR if you did.

Here is what I am going to tell you... 30 years in the biz working with dns.. When you set more than one, you are not sure which one is going to be used.. This how dns works..

If you set a dns client any os be it windows, linux, bsd and you set more than 1 NS.. you are not sure which one is going to be asked..

If you ask unbound running on pfsense and you want it to resolve your PTR, you better set the in-addr.arpa zone override for the ptr your going to want to look up.. Or you going to have issues, unless pfsense has the local resources for those setup on it, say via a host override.

johnpoz

@hspindel said in bandwidthd and name resolution:

I also tried a domain override of 1.1.192.in-addr,arpa and it didn't help either.

Because that is not the zone now is it..

hspindel

@johnpoz
Yes, as I said above I have DNS overrides set now for both sci1.com and 1.1.192.in-addr-arpa.

As a last resort, I tried restarting bandwidthd and that didn't help either.

hspindel

@johnpoz said in bandwidthd and name resolution:

@hspindel said in bandwidthd and name resolution:

I also tried a domain override of 1.1.192.in-addr,arpa and it didn't help either.

Because that is not the zone now is it..

That is my local zone.

johnpoz

your using 192.1.1 locally? The space owned by Raytheon..

NetRange:       192.1.0.0 - 192.1.255.255
CIDR:           192.1.0.0/16
Organization:   Raytheon BBN Technologies Corp. (RBTC-Z)
RegDate:        1989-01-04
Updated:        2022-08-12
OrgName:        Raytheon BBN Technologies Corp.

Here this is how simple it is -- I created a reverse zone on ns on my network at 192.168.9.10.. I setup the override in pfsense for an in-addr.arpa that would cover..

I query unbound on 192.168.9.253, it asks 192.168.9.10 and I get an answer

I remove the domain override - no worky worky ;)

hspindel

Yes, I am using 192.1.1.0/24 locally.

I realize I'm not supposed to do that. It goes back to a mistake I made fifty years ago in setting up my network (when I was young and stupid), and I've never corrected it because I'm afraid I wouldn't find all the places where 192.1.1 is hardcoded, something would break, and I'd spend a long time chasing it down.

The only downside to this mistake is that I cannot access the Raytheon site. Since I don't care about that site, it doesn't matter to me. Since my network is NAT'ed, the rest of the world doesn't know about this mistaken configuration.

bandwidthd started resolving names correctly now. I think it's because I had to restart the bandwidthd service.

Anyway, problem solved. Thank you for the pointer to DNS overrides settings.

johnpoz

@hspindel you also understand roots points that in-addr to rays ns right

;; AUTHORITY SECTION:
1.192.in-addr.arpa.     3600    IN      SOA     adns04.ray.com. hostmaster.bbn.com. 2019050346 1800 300 604800 7200

Hard coded where? Why would you ever hard code an IP? You have applications you wrote that hard code to some 192.1.1 address?

hspindel

@johnpoz said in bandwidthd and name resolution:

@hspindel you also understand roots points that in-addr to rays ns right
;; AUTHORITY SECTION:
1.192.in-addr.arpa.     3600    IN      SOA     adns04.ray.com. hostmaster.bbn.com. 2019050346 1800 300 604800 7200

All I know is that it's been working without issue for decades.

Hard coded where? Why would you ever hard code an IP? You have applications you wrote that hard code to some 192.1.1 address?

If I could remember all the places it's hardcoded then it would be easy for me to change. As to where - lots of config files scattered across my network.

johnpoz

@hspindel said in bandwidthd and name resolution:

All I know is that it's been working without issue for decades.

So you have been running your own NS, with pfsense as your router for decades? No duh devices pointing to your NS can resolve stuff it has ptr records for.

pfsense itself uses itself to resolve, why would it go ask something else for a ptr until you told it too.. If he queries the roots for PTR of 192.1.1 where would he go? If the record is not local - he would ask the raython NS because they own that space.

Did you set it up to forward to only your NS? So it would have to ask it? No you had multiple ones - if it couldn't resolve, then clearly it didn't ask your authoritative NS for it, or it would of gotten answer, etc.

You force it to ask your NS when you put in a domain override, etc.. that is how dns works..

hspindel

@johnpoz
pfSense is new for me. Everything else has been running a long time.

I only noticed pfSense couldn't resolve local names when I installed bandwidthd. There was no need for pfSense to resolve local names before that.

Thank you for the pointers to DNS overrides.