NTP server pools can't be resolved [Solved, 2 problems in 1 post]

[techtester-m]

Hi,

NTP servers (pools) couldn't be reached and Cloudflare, which I'm using as my DNS, wouldn't even resolve them (ping etc.) and instead would return their own time server(s) address, so I tried switching to Google's and encountered another wierd problem: While I use Cloudflare DNS servers under the General Settings and set the DNS resolver to forward all queries to those servers, everything works fine. As soon as I change from Cludflare to Google (8.8.8.8) or anything else there's no Internet and I can't resolve or ping anything.

Any idea?

Thank you,

[heper]

@techtester-m perhaps your ISP is blocking traffic to Google DNS?

[Gertjan]

@techtester-m said in NTP server pools can't be resolved:

Any idea?

You do lnow it worked well right after you installed pfSense.
Then you changed something.
And things stopped working.

So, easy solution : no surprise : use default DNS settings and you'll be fine.

Take note :
Cloudfare, Google, what ever companie you want to use for your DNS needs (because you do not trust the Internet's main root server ? *** ) : when they come back with "Not found" or "Not now" or just nothing because of a routing issue.
I do not what to be confounded with a "complotist" but understand that they decide what answer you get, if one exist, and when, and what is good for you.

On the other hand : we all used DNS forwarders in the past : our ISP's equipped our ISP boxes with such a program, and it should be set up correctly. Back then, settings were hard coded. using pfSense, you are in full control.

The Internet root servers are 13 servers controlled by non-profit, neutral organisations. One after the other gets used up until one gets an answer for you. If none are reachable, the entire (!!) Internet is down,something that did not happened yet.

**** Cloudfare, Google, they all use these 13 main root servers also - without exception.

edit : @heper has a point : their are (still) today ISPs that block all DNS requests, except the ones to their own DNS services. In that special (these days) case the Resolver won't work, as your Internet connections is severally crippled. The forwarder mode of the resolver - or dnsmasq, the forwarder, has to be used, and should use the DNs(s) of your ISP.

[techtester-m]

@heper But monitoring a gateway (VPN) using Google's DNS works just fine...Maybe I'm missing something here.
Also, unless my ISP has some kind of a deal with Cloudflare, I don't see why no other DNS would work.

[techtester-m]

@Gertjan We've talked about this before, me and you. I don't like the ISP and others of the likes + These 13 servers don't support DNSSEC & DoT. So I rather give it all to Cloudflare or others than the fing ISP, which will get sht because it is all encrypted. Sort of like "Stick it to the man" approach but giving it to a different "man" LOL.
This my gamble for now.

Now...about the pfsense settings. I didn't change anything that could logically cause that behaviour.
I'll post few screenshots for you

[Gertjan]

@techtester-m said in NTP server pools can't be resolved:

These 13 servers don't support DNSSEC & DoT.

As far as I know, today, no DNS facility supports both.

You can use DNSSEC only when you use the Resolver, and this Resolver uses the 13 root servers. That's pfSense's default setting.
When you are "forwarding", DNSSEC is out.
DoT can't be used - not yet - using the 13 root servers. You have to "DoT" to a DNS (resolver) like Google, Cloudfare that support this protocol.

You have to make a choice, you can't have both.

[techtester-m]

@Gertjan Please check the screenshots below (I can post just a few in one post or else it would give spam error):

[techtester-m]

@Gertjan The rest of the screenshots:

[Gertjan]

You use the Resolver in forwarding mode.

These :

are the ones the resolver should use for the DNS requests.

And it can find these two (1.1.1.1 and 1.0.0.1) using this outgoing interface :

.... which will fail.
1.1.1.1 and 1.0.0.1 does not 'live' in your pfSense.
1.1.1.1 and 1.0.0.1 are reachable (probably) using your WAN interface, or one of your VPN WAN type interfaces.
Pointing a process that runs on 127.0.0.1 to 127.0.0.1 will .... fail.

The "will always work" setting for "Outgoing" is "all", or a selection of your wanted outgoing interfaces.

[techtester-m]

@Gertjan So I should use "Localhost" as the outgoing interface only when I use pfsense as a "pure" dns resolver?
When forwarding to others, the outgoing interface should be either "all" or simply my default gateway, right?

That would be "best practices" if you will....correct?

@Gertjan said in NTP server pools can't be resolved:

1.1.1.1 and 1.0.0.1 are reachable (probably) using your WAN interface

But if it can reach them through the WAN (default gateway) why wouldn't it do that with any other DNS server?

[Gertjan]

@techtester-m said in NTP server pools can't be resolved:

So I should use "Localhost" as the outgoing interface only when I use pfsense as a "pure" dns resolver

See :

Using "Localhost" == itself, won't work.

When you use the Resolver as a Resolver, it should be able to find "at leats one of the 13". I presume you do not host locally one of these main Internet Root servers ;)
So, you have to indicate at least one interface, or All interfaces so unbound / the Resolver can find a way out.

@techtester-m said in NTP server pools can't be resolved:

When forwarding to others

The same reasoning applies.
You have to indicate at least one interface that it can use to go out.
It actually knows that "1.1.1.1" and "1.0.0.1" are not locally aviable on of of your LAN type networks.

Tou might ask : why is localhost even listed as an option here ?
I guess there is a reason - it's just me not finding an example that justifies its presence on that list.

[Gertjan]

@techtester-m said in NTP server pools can't be resolved:

But if it can reach them through the WAN (default gateway) why wouldn't it do that with any other DNS server?

Well ... as said above.
WAN == your ISP .... they are filtering ??
Other WAN interfaces == other "ISPs" == your VPNs : they filter ?

Up to you to discover who does what - what works with who - what doesn't work with who etc etc.

[techtester-m]

@Gertjan said in NTP server pools can't be resolved:

When you use the Resolver as a Resolver, it should be able to find "at leats one of the 13". I presume you do not host locally one of these main Internet Root servers ;)

What?! That was my logic exactly back then when we talked before about VPNs and DNS etc. I remember you told me YOU yourself use "Localhost" and I should do too because using a VPN interface would fail to resolve after a reboot because it wouldn't be able to start without someone else to resolve it first (when used with FQDN instead of IP).

Regardless of these settings, pfsense should still cahce results and search in locally (127.0.0.1) first right?

[Gertjan]

@techtester-m said in NTP server pools can't be resolved:

I remember you told me YOU yourself use "Localhost" and I should do too because using a VPN interface would fail to resolve after a reboot because it wouldn't be able to start without someone else to resolve it first (when used with FQDN instead of IP).

Interesting. Where was it ?

The unbound config command : https://nlnetlabs.nl/documentation/unbound/unbound.conf/ - look at that page the explanation of this setting "outgoing-interface" setting.

When a DNS request comes in, an answer will be send back if the resolver/unbound cache contains a valid (already recorded) answer. If not, and the request isn't using a local zone, the request will get forwarded or resolved up stream
These are my words, but I strongly advise you to read the official ones, now you know where the unbound doc is ;)
nlnetlabs.nl are the authors of unbound, which is used "as is" by pfSense.

Images above :
You activated DNSSEC while using Forwarding mode : not an issue, but useless. DNSSEC, as you should know, has no meaning while forwarding.

You have "DHCP Registration" activated. That can have consequences - see the hundreds of other posts related that that specific subject. Do as you wish. Just understand why you should, or shouldn't.
This is the are, probably only setting in pfSense that I would change from it's default value.

Firewall rule :
Your second rule with a destibnation of "127.0.0.1" is not possible. An address like 127.0.0.1 is only possible "in" the router/firewall itself, and can not come into an physical interface like "LAN". The Sates counters will stay at 0/0 for an eternity == rule did not apply.

ntp servers :
Take the two letter code of your country - and create an URL like :

and done with NTP.

[johnpoz]

@Gertjan said in NTP server pools can't be resolved:

When you are "forwarding", DNSSEC is out.

No not really true - when you forward to a resolver that does dnssec is automatically done for you.. You do not have to tell your local forwarder to ask for it..

Have been over this multiple multiple times.. There is zero reason to ask for dnssec when forwarding.. Where your forwarding either does it or it doesn't.

If your forwarding to a resolver over dot, and it does dnssec - then it would do dnssec, be it you using dot or doh or not.. dnssec is a setting on a resolver, be it you running your own locally, or forwarding to one.

[techtester-m]

@Gertjan said in NTP server pools can't be resolved:

You have "DHCP Registration" activated. That can have consequences

Yeah, I have no idea why I kept that from back then when I was experimenting pfsense. I don't care whatsoever about random dynamic DHCP leases. Only statics and OpenVPN. Thanks for pointing that out :)

@Gertjan said in NTP server pools can't be resolved:

Your second rule with a destibnation of "127.0.0.1" is not possible

Well...this is not my rule. It was auto created by pfsense after I added port forwarding for LAN net to force all DNS (53) to be answered by what is set on pfsense. Could you rethink that or explain me better?

[Gertjan]

Thanks for the heads up.

The word "out" is to short for something that needs to be repeated every week or so .... ;) (and is repeated every week, or so)
8.8.8.8 and other, who are actually resolvers, do support DNSSEC on their "request" side. It's the link between our forwarder (pfSense) and them that somewhat breaks the DNSSEC concept. If that link is over TLS (DoT) then you're sure the info isn't tempered with : you're sure it comes from 8.8.8.8.
But the DNSSEC RFC does not state that some one should trust 8.8.8.8

To see what DNSSEC does, cehckout https://dnsviz.net/d/test-domaine.fr/dnssec/ - all the mine (pointers) between all the circles are checked and verified.
Their is a yet another root concept : the "20326" trusted root key at the top. This key is build in and checked upon each unbound startup. based on this key, all other keys on a lower level are signed => trusted.

[techtester-m]

@Gertjan Just changed dns resolver ONI from localhost to all. Set 8.8.8.8 and 9.9.9.9 under general settings, restarted unbound, reset states....still same result. No resolving.

Edit: perhaps my ISP blocking them (on port 53)? And if so why would the stupid ISP block completely and not simply give its own answer and just resolve the request?

[Gertjan]

@techtester-m said in NTP server pools can't be resolved:

perhaps

We asking yourself these questions ?
You have a "pfSense", he'll tell you, just put it to work.

Console / SSH (true, the click click show stops, so the real power can be deployed) ;

dig duckduckgo.com +trace

and admire the result.

I'm seeing :

.                       79203   IN      NS      c.root-servers.net.
.                       79203   IN      NS      h.root-servers.net.
.                       79203   IN      NS      k.root-servers.net.
.                       79203   IN      NS      d.root-servers.net.
.                       79203   IN      NS      g.root-servers.net.
.                       79203   IN      NS      b.root-servers.net.
.                       79203   IN      NS      m.root-servers.net.
.                       79203   IN      NS      e.root-servers.net.
.                       79203   IN      NS      l.root-servers.net.
.                       79203   IN      NS      a.root-servers.net.
.                       79203   IN      NS      i.root-servers.net.
.                       79203   IN      NS      j.root-servers.net.
.                       79203   IN      NS      f.root-servers.net.
.                       79203   IN      RRSIG   NS 8 0 518400 20200709050000 20200626040000 48903 . T12wT/714x73vuIWxAMaZaA4j0D6Pamf3VOICYYm17sRHElWtXf29Xsa raslWtAVqjHBJHpErqlZD3Qq3fd6hboj9Xbri8Ik/irTa78m9zYwO7kW s6BrYUloEzzYDL0eZi8O4gv7CKlnr8mfGrjYkLtUUTheUguxdeuOi/Nv pEpqoJPg0qLEf4jaBocexyi0hmCjRk5sGisQJ1oUTYu32PwrEtHJ2NOw WGnBxjbRW1uR0RNqFZXJ9D2NelTNym9t4LMu1+ENC2l+bq9PoWBSdYke sat/USsbKC5QlMeGYPUodvcJiGvpqTYgFQYjpxTOS0K8s/CoUUcRVFBS 6uqveg==
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20200709050000 20200626040000 48903 . mRy6ZWw24zU61QmFBnFUULJe9md6RKkgIF4uuu78rbn9nD/mUBvAOOxM bJWR4wTbck5sCYmLynXCkaxcAXkMvhC6dVJDlmWP1u4SnaBTJzZWN+t+ wWzHCervVDyY4ileHiyn5sVFj87OasQ5vo4uupME463cJ9TCETs/or8o 8bkhD3nezxbixiZVWw0m43W6z2IACBETUR7BlSdCe9VZ3lk5/HdXMVnT Y198/Ranjg/DfM4oacZhfjexYHHlPFl1bgRQ5UDtvddHpIlCFG8s21aV Rff7ftX9eB2MywOH2ewFWg3gtqsVtp21eE5ZqknHOgQAsIoeBqsn8vnR DTPVQQ==
;; Received 1174 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 97 ms

duckduckgo.com.         172800  IN      NS      dns1.p05.nsone.net.
duckduckgo.com.         172800  IN      NS      dns2.p05.nsone.net.
duckduckgo.com.         172800  IN      NS      dns3.p05.nsone.net.
duckduckgo.com.         172800  IN      NS      dns4.p05.nsone.net.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200630044218 20200623033218 39844 com. XLLl9R6DyHumuL5DcLJ502J0Q1wgWp3yCHNR3bmyNznc45/NjPgMt82/ LZcr3B8udPvMahuZAGbTLFcD+l5JnGFznFgqIdpKDzhPO0jY1CFVBN81 k4CNg7Z/35vTEv3vO6qKo6uN7tIW5qWnuiOF4NejSK5kU34PG/ZFVTjw jY6szHRtWK2ru0ipvUwBLWzuc67e2EdMQPRGQGyBl8pV4g==
BN1FJS0UO0RMBT477B345GNU6A9CFODA.com. 86400 IN NSEC3 1 1 0 - BN1FSPPU7UST4HCP0ADMG9U117OMTH0V NS DS RRSIG
BN1FJS0UO0RMBT477B345GNU6A9CFODA.com. 86400 IN RRSIG NSEC3 8 2 86400 20200701054124 20200624043124 39844 com. eU7OSt9NYB7el3Bqfar0o6Pz1WOpW9aHciC98kqfj0fDjGhnlNKq55wP A4uyXkFfADKvrKgcABbF3Be3gBK1RRdLlDzypXJKiFlhmhTo53R2pwam bJcRyZKODyx+0QOsRqO5QXwZ85dW8Xm6Lj7wccgFacSJVKCSmVS/hnnh Qy4xvm/t0ENOmFtT82pABN0DicsWanRCbcVf04faHIdAKQ==
;; Received 681 bytes from 2001:501:b1f9::30#53(m.gtld-servers.net) in 115 ms

duckduckgo.com.         200     IN      A       40.114.177.156
;; Received 59 bytes from 198.51.45.69#53(dns4.p05.nsone.net) in 37 ms

Clearly, you can see that the list with "13" is used.

Alraedy cached was the fact who handles dot com - so .com is questionned.

"j.root-servers.net" = number 10 answered, and gave the domain name servres that handle the domain duckduckgo.com : dnsx.p05.nsone.net (where x is 1 to 5).
Finally, dns4.p05.nsone.net gave the answer - just for me : 40.114.177.156

The other lines are DNSSEC related, not really readable for humans.

Btw : You do not have the usual "WAN" interface but a list of VPN connections.
These are just perfect to introduce DNS related issues.

What about deleting (de activate) them all, just use a WAN - and do your tests.
Then add just one (1 !) VPN, and re test extensively. The moment things go wrong, will be the moment you know what to correct / do better.

[techtester-m]

@Gertjan
This is my result (same as yours only different NS gave the answer):

duckduckgo.com.		200	IN	A	40.114.177.156
;; Received 59 bytes from 198.51.44.5#53(dns1.p05.nsone.net) in 60 ms

What now? I still can't use any DNS server other than cloudflare

Edit: Just disabled forwarding mode, rebooted pfsense (just to be sure) and still the same behavior with NTP, in addition to the still existing problem of not being able to forward to Google. So...the conclusion would be that it has something to do with my ISP or something else other than pfsense? I'm lost here...

@johnpoz