Unable to resolve acb.netgate.com
-
@VMlabman said in Unable to resolve acb.netgate.com:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52553
that is not resolving - that is NX.. but you did abc vs acb And where exactly is your client pointing to for dns, 127.0.0.53 is a typical IP clients that are using say netplan would use, because it points to local instance that forwards somewhere.
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
see my ubuntu vm does that same thing
user@UC:~$ dig acb.netgate.com ; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> acb.netgate.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55014 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;acb.netgate.com. IN A ;; ANSWER SECTION: acb.netgate.com. 3600 IN A 208.123.73.69 ;; Query time: 60 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Sat Apr 20 14:17:41 CDT 2024 ;; MSG SIZE rcvd: 60 user@UC:~$You can normally see where exactly your client is pointing with
user@UC:~$ resolvectl status Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (ens3) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.3.10 DNS Servers: 192.168.3.10 DNS Domain: home.arpa user@UC:~$ -
I’m no longer resolving by default DHCP leases into DNS by default. I click that off a couple days ago but I’m still having the issue the ABC which is the gate back up is not resolving air come up any other ideas out there to help me out I’m stuck on this one it does resolve, the command, prompt or terminal
Thank you,
-
@VMlabman you sure using the correct name? Its acb.netgate.com not abc.
-
Thank you for your reply. Yes, I am sure I am as I have made no changes to that area of pfSense and it does work a lot of the time. Screenshot attached. What else can I check within the firewall? What do you suggest?
Reguards,
-
@VMlabman so seem to be odd ball times. Are you making a change when that happens, that would/could effect your connection or that resolving? I just had this happen to me as well... But it was because unbound was being restarted..
If you ask me they have a horrible short ttl on that record
;; QUESTION SECTION: ;acb.netgate.com. IN A ;; ANSWER SECTION: acb.netgate.com. 300 IN A 208.123.73.69So that is almost always going to have to be resolved on the spot.. Because its not cached for more than 5 minutes.. And if nothing is asking for it, it won't be prefetched etc.. And prefetch isn't even a default setting.
Let me call @stephenw10 for his take on that ttl, why would it be so low is beyond me.. I doubt that IP is going to be changing that often?
I might see it happen less often because I have a min ttl of 3600 set on my unbound.
-
@johnpoz said in Unable to resolve acb.netgate.com:
@stephenw10
How do I go about making the change to the ttl on pfSense? I am newer to this stuff and this is my first build I have dont more then basic browsing of the web with.Thanks
-
@VMlabman you can't change the ttl they hand out, but you can set min ttl in unbound.. So any record that it resolves if the ttl handed to you is lower than your min, it sets it to the min you have set..
Go to the unbound settings, advanced and scroll down.
Keep in mind this is an advanced setting, and could have issues.. I have used this setting for years and never ran into any issues. But its not considered good practice to alter the ttl set by some domain.. But then again ttls of 60 seconds, or 5 minutes or 10 minutes etc are just insane low.. Unless the IP was dynamic and changes all the time, or you are in the process of changing the record to a different IP..
And this might not help, but it will help in having to lookup that record every 5 minutes.. Since now it will be cached for an hour. You could set it higher even if you want.. But again its not good practice to alter the ttl that someone has set.. They normally set a ttl for a specific reason.. Then again they might not have a clue, and where they are hosting dns sets it default to low? Or maybe they changed it and didn't raise the ttl back to a sane value.
-
Mine at this point is set to 0. Is there a way to change this for a single domain ie. acb.netgate.com or make a atatic entry anyware and test it that way?
Thx,
-
I am trying to see if it helps. i don't know if this is even a good idea or not however it's easy to remove and doesn't affect any other domains.
I put a static entry in DNS Resolver Domain Overrides
-
@VMlabman yeah that should help unless the reason you can't resolve it is that unbound is not running.
-
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. -
@VMlabman I just ran into this - but this seems more like just acb didn't answer quick enough, not that it didn't resolve
-
@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,
-
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,
-
@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.
-
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,
-
@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.
-
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.
-
@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.
-
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.
