Unable to resolve acb.netgate.com

[Gertjan]

@VMlabman

I'll give you a list with exploitable ideas :

You've already met this one :
Uncheck :

Also, when you installed pfSense, it was not "broken" : DNS worked just fine.
So, what about trusting Netgate :

Always keep an eye on unbound : I use this.
Why ? Because a "always running" unbound is important for my DNS stability.
You'll say : Hey, your unbound is always restarting !! That's because restart it manually, as I try out things a lot while answering DNS questions here on the forum ^^
But basically, I use the settings Netgate gave me a decade ago. And oh boy, I never have DNS issues. I'm not wondering why ^^

Take note : I use pfBlockerng, and pfBlocker tends to restart unbound.
I've set my dnsbl feeds to be re downloaded every week, not every hour.

[johnpoz]

@VMlabman I just ran into this - but this seems more like just acb didn't answer quick enough, not that it didn't resolve

[VMlabman]

@Gertjan said in Unable to resolve acb.netgate.com:

I've set my dnsbl feeds to be re downloaded every week, not every hour.

Will trusting Netgate and checking DNS Query Forwarding break my DNS Over/TLS on 853 ?

Thanks,

[VMlabman]

@johnpoz

I get it from the Auto Backup when I make a change to the firewall it uploads a configuration change / backup to Netgate. It's a real pain in the tush to keep seeing the error. I am going to try what @Gertjan suggested I give and shot and check DNS Query Forwarding to see if that helps.

Thank you,

[Gertjan]

@VMlabman said in Unable to resolve acb.netgate.com:

Will trusting Netgate and checking DNS Query Forwarding break my DNS Over/TLS on 853 ?

Unbound, when resolving, is using the internet's root DNS servers directly, and from there on it will use one of the available TLD server (dot com dot org dot net dot whatever) to find the DNS name server, for example de DNS server of facebook if you are looking for one of the IPs of facebook.

If you are forwarding, you are forwarding to some other resolver, who does exactly the same thing for you.

So, the question can be reformulated in : do you trust the Internet ?
Or do you trust some one else, who then on it turn trusts Internet ?

I tend to say : more trust is gained when removing needless steps. The less you have to trust, the better it is.

The original "resolve yourself directly" can have one more massive advantage : if the domain your looking for was set up to use DNSSEC, you (unbound, pfSense) will know that the answer is valid, without being spoofed.
Example here : I own (rent !) this domain. Hover over :

There you see my A (web server) address. That answer is guaranteed, as it was 'signed' using certificates from top to bottom. Same thing for the MX, AAAA, NS, any TXT fields etc.
The chart also shows the complete ordinary resolving process, which will happen in parallel. all steps will be verified.

Example : if you use a forwarder, you can't use DNSSEC, its meaningless. This means you could fall for what is known as DNS spoofing. DNS Spoofing is .... bad.
One simple example : If I could spoof one or more "microsoft.com" (sub) domain name DNS requests, I could have your PC point to my infrastructure instead of "microsoft.com". 5 minutes later your OS will download and appy updates from my servers, not "microsoft.com". 1 minutes later I own your PC, and the other x billion also.
Game over for the world's economy right after that.
Game over all together shortly after that.

The good news : all serious resolvers (1.1.1.1, 9.9.9.9 etc) you can forward to, are doing the dnssec test for you, if available - if the domain name seearch for has DNSSEC set up.
The bad news is : if they (the resolver you are forwarding to) have a security issue, you're gone.

And I get it : there is another thing going on here : forwarding permits you to 'hide' (== protect) DNS traffic between you and the resolver you forward to.
Internet's original DNS, the root servers, TLDs and domain name server don't allow this.

[ AFAIK : Why : ? because DNS traffic is small, of just one packet "up and down", and needs to be done as fast as possible. Using TLS for all DNS traffic will multiply the resources needed by .... 1000 time at least for the DNS servers. using a TLS connection is one thing, creating a new TLS connection for every DNS request is another, even worse ....

Read this one : https://news.ycombinator.com/item?id=16742638link text and discover why 'countries' (or other entities) maybe don't want to push to 'all DNS over TLS' ....
Now, we have all these people that are forwarding over "some resolver" and they think they are safe because they use DNS Over/TLS on 853.
Right.
You just made live easier for your "local government" : all they have to do is putting a tap at (in !) this resolver, and all info is there, nicely centralized.
Take note : see the resemblance : VPN ISPs could function the same way ( ).
All this boils down to : "you do you best to make yourself safe, and while doing so you managed to make spying on you easier (this is the "everybody is happy now" concept)". In the case of using VPN ISPs, add "... and you are even paying for it".

Btw : ones in while, I do test forwarding to 9.9.9.9 or 1.1.1.1 or some one else. Using TLS of course.
It always worked great for me, never had any issues.
I always fall back to plain simple resolving. As I strongly believe that 'keep things simple' is the way to go. DNS was designed 50 years ago to work 'like that' so I adhere.

I'm aware of this : it's more a politics thing actually. There is no good choice to make here. It your choice, and mine.

[VMlabman]

@Gertjan

That was an incredibly informative reply absolutely enjoyed reading it great information. I’ve been costing myself valuable transit time and packet size. The information you provide actually makes me believe I’m doing nothing with DNS Over TLS for myself given the fact that I can do the same thing with the option you provided, definitely because I have nothing to hide by encrypting my DNS request. The ISP can see where I end up on the Internet by IP address, regardless.

This suggestion along with reducing the intervals that I am updating PF Blocker & Snort DSBL lists. Now unbound won’t restart the DNS resolver so often. This should really be helpful in a couple different areas slight performance increase less DNS outages even as so temporary they are. They could be very well be the source of failed resolving abc.netgate.com

I’ll give her a shout I could always put it back the way I had it. That’s what having a home lab is all about testing and learning. Thanks for the great lesson.

Have a great day,

[johnpoz]

@VMlabman said in Unable to resolve acb.netgate.com:

The ISP can see where I end up on the Internet by IP address, regardless.

There is that, but also when you connect to say https://www.domain.tld - this fqdn is sent in the sni in the clear.. So not only they know what IP your going to, but simple sniff of the traffic can give them the exact domain your going to.. Since its possible that some sites IP hides in the vast amount of sites served off a CDN.

Until such time that esni (dead), long live ech is widely deployed the sni is in the clear and anyone that can see the traffic can see what site your connecting to via this.

Not really a fan of dot or doh, and they misrepresent the benefits or the privacy/secure of using it. Its not like it can't have valued use cases.. And with doh, they like to turn it on without full user acknowledgement.. Which is not the right way to go about getting users to use it.

[VMlabman]

@johnpoz

More good information. Enjoying it. I went into pfSense and I already did have DNS Query Forwarding enabled so I just disabled Use SSL/TLS for outgoing DNS Queries to Forwarding Servers. I also made the adjustment to the update intervals for pfBlockerand Snort.

[johnpoz]

@VMlabman throw some info at you - why resolving is better than forwarding ;)

When you forward, your at the mercy of that site to be up.. While they have very robust networks, and they shouldn't be going down.. They can and they have. At least in some parts of the world.

So you can try and mitigate that causing you issues by forwarding to more than 1 service. But if these services filter, you run into the issue where service X filters A, but service Y does not - which one are you going to be using at any given time? So maybe some site it filtered, or maybe its not? You can have different results handed to you based upon which NS you actually talked to in their vast anycast network that might hand you different IPs that may or may not be optimal for where your at..

When you resolve, the whole freaking internet would have to be down.. For your dns to be down. If the roots or gltd servers are down - the whole internet is down.. Doesn't matter what service you might be using for your dns.

I just don't get the advantage of handing over all of my dns queries to some service.. They might provide some good filtering, sure ok - no thanks I can do my own filtering thank you very much ;)

I will resolve, and talk directly to the NS for the domains I am wanting to go to.. I have no need or desire to hand over ever single dns query I do to some service.. What is better for privacy, while you might hide your dns from your isp, your just handing it over to someone else on a silver platter.

And like you discovered, sending your dns via encryption to some services doesn't actually hide really anything from your isp. They for sure know where your going by IP and port, and they also can very simple grab all your sni info.

if you are concerned about isp knowing where your going - you need to encrypt not just the dns, but the data flow as well.

[VMlabman]

@johnpoz

Once again thank you for all you help and time. So far since I have made the changes I am no loner getting the can't resolve abc.netgate.com error. Lets see what happens after a little more time.

[Gertjan]

@VMlabman

Check here : Diagnostics > Configuration History
These are the moments your pfSense syncs the local config with "acb" (non abc ^^).

Now we know that acb.netgate.com has a TTL of

acb.netgate.com.        30      IN      A       208.123.73.69

= 30 seconds ( dono why, but's that very short )

every time your pfSense uploads your config it has to resolve again "acb.netgate.com."
But hey, as long as the NS servers of netgate.com aren't down, this will work.
Because : Internet, see above, isn't down.
And I presume your connection isn't down.
And - important - unbound must be up and running all the time - not restarting very often - see Status >System Logs > System > DNS Resolver to check that.

I've added myself an extra gadget : Services > DNS Resolver > Advanced Settings :

this will take care of having a cached, resolved result of expiring.
When it expires, after 30 seconds, imho, unbound will refresh it. This means I'm hamering the netgate.com NS servers with a DNS request. Not my fault, as they set the TTL so low.

I use pfBlockerng, so I have some; insight about what unbound is asked to do :

Also : Status > DNS Resolver and I tjhought I would find our acb.netgate.com here but noop.
But all the NS servers of every domain name I visited for the last past ..... days, are there.
This means that 100 % resolving, from the top root servers down to the domain name server is actually a rare event.
unbound will keep the IP of the TLD, for example : the DNS server that hosts all the dot com domains and it will also keep the IP of the domain name (== "NS") of every visited domain name.
( and even refresh the TLL when it times out - see setting above )
So, when it needs to know what the IP of acb.netgate.com is, it will ask it directly to one (there must be 2 at least) of these NS = domain Name Servers:

ns1.netgate.com.        1436    IN      A       208.123.73.80
ns2.netgate.com.        8       IN      A       208.123.73.90
ns3.netgate.com.        8       IN      A       34.197.184.5
ns1.netgate.com.        1436    IN      AAAA    2610:160:11:11::80
ns2.netgate.com.        8       IN      AAAA    2610:160:11:11::90
ns3.netgate.com.        8       IN      AAAA    2600:1f10:4c5e:6701:e4b2:c059:13c5:64fb

Lets check 'manually', and ask the first NS "208.123.73.80" if it knows the A of acb.netgate.com :

[24.03-RELEASE][root@pfSense.bhf.tld]/root: dig @208.123.73.80 acb.netgate.com A +short
208.123.73.69

Nice.

Another check :

dig @208.123.73.80 acb.netgate.com AAAA +short

No answer, so no IPv6 for acb.netgate.com (strange ...)

[mike123]

Re: Unable to resolve acb.netgate.com

Login to the shell and type
dig acb.netgate.com

If you get no reponse
i.e. ;; communications error to 127.0.0.1#53: timed out

go to System/General Setup

DNS Server Override -> Allow DNS server list to be overridden by DHCP/PPP on WAN or remote OpenVPN server

Solved the issue for me

[VMlabman]

@mike123

Thank you for the advice. However I what to route all my DNS through DNS over TLS to Quad9 and making that change would allow any DNS server provided by DHCP from my ISP to be used. I rater avoid that for now. It's not taking place as often as it was anymore so I am not as concerned with it as much now.

[johnpoz]

@VMlabman said in Unable to resolve acb.netgate.com:

would allow any DNS server provided by DHCP from my ISP to be used.

Not exactly, it would allow pfsense to use it for its own lookups. Which wouldn't be via tls.. Sure any of those could be used in forwarding, but if they do not support tls then forwarding to with tls enabled in unbound would fail. Only pfsense non tls queries would work.. If your having some issue with unbound being able to resolve acb.netgate as specific times.

Vs putting in your isp dns, or allow for dhcp to add.. You should be able to just allow pfsense to fall back vs just pointing to unbound on loopback.. I believe that is the default setting anyway.

The only way pfsense own queries for anything are via tls, is when it asks unbound to do the lookup, if it directly looks up something from quad9 since its in your list, it would just be a standard dns query over 53.

What is that setting in your general setup?

[VMlabman]

@johnpoz

Here are my DNS Settings under General & the Setting in Resolver.

Side note how did you capture that screenshot with the pop down menu open? Every time I try It closes on me in Sharex (Windows) and Shutter (Linux) can you tell me what program you are using?

---

[johnpoz]

@VMlabman so see this setting

You have it set to ignore remote, so pfsense will never ask anything other than unbound on 127.0.0.1 which if fails will mean that no you will not be able to resolve acb.netgate.

If you change it to default which is fallback, if it tries to look up acb.netgate and say unbound is restarting or something it would fall back to asking quad9 via just normal in the clear dns over 53 for it.

No clients would ever be able to do that, only pfsense.

[Gertjan]

@mike123 said in Unable to resolve acb.netgate.com:

Login to the shell and type
dig acb.netgate.com

If you get no reponse
i.e. ;; communications error to 127.0.0.1#53: timed out

Iif "Login to the shell and type" is the console or SSH access of pfSense, and you get a "127.0.0.1#53: timed out" after "dig acb.netgate.com" then that means that the dig command couldn't connect to 127.0.0.1, port 53.
That means that unbound isn't running, or listening on 127.0.0.1 port 53 (localhost).
That is not normal at all.
First : : Check if it is running :

[24.03-RELEASE][root@pfSense.bhf.tld]/root: ps ax | grep 'unbound'
41201  -  S        0:07.76 /usr/local/sbin/lighttpd_pfb -f /var/unbound/pfb_dnsbl_lighty.conf
86447  -  Ss      25:07.40 /usr/local/sbin/unbound -c /var/unbound/unbound.conf
21124  0  S+       0:00.00 grep unbound

(the second line == ok )

and check on what interface it is listening :

[24.03-RELEASE][root@pfSense.bhf.tld]/root: sockstat | grep 'unbound'
unbound  unbound    86447 3   udp6   *:53                  *:*
unbound  unbound    86447 4   tcp6   *:53                  *:*
unbound  unbound    86447 5   udp4   *:53                  *:*
unbound  unbound    86447 6   tcp4   *:53                  *:*
unbound  unbound    86447 9   tcp4   127.0.0.1:953         *:*
unbound  unbound    86447 10  dgram  -> /var/run/log
unbound  unbound    86447 12  stream -> [86447 14]
unbound  unbound    86447 14  stream -> [86447 12]
unbound  unbound    86447 15  stream -> [86447 16]
unbound  unbound    86447 16  stream -> [86447 15]

The first 4 lines means : on port '53' :
For all protocols : TCP and UDP and TCP and UDP
This means all interfaces, which include '127.0.0.1'.
Btw : line 5 is unbound listing on localhost, the control port 953 TCP.

This option :

DNS Server Override -> Allow DNS server list to be overridden by DHCP/PPP on WAN or remote OpenVPN server

exist for very ancient reasons (before 2000 ?), when you had to use the ISP DNS servers, as resolving was 'expensive' and an internet connection was metered, and very slow (POTS modem uplink).
Many ISPs still propose a DNS or two, but I guess no one is using them anymore.
Why getting the info from 'some one' if you can get it from the source ?

[Courierdog]

@Gertjan said in Unable to resolve acb.netgate.com:

Diagnostics > Configuration History

Note: the Command is: Diagostics-> Backup & Restore -> Config History