Out of the box install, DNS broken (DNSSEC?)

jimp

Check your system clock.

The #1 way I have seen that behavior is when the time is way off out of the box.

madcatinc

Looks like you are on to something!

I changed the time servers to 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org and 3.pool.ntp.org (and rebooted just for good measure) but it still seems to be having problems resolving the hostnames. Is this a chicken and egg situation? Is it trying to use the pfsense resolver to resolve the ntp hostnames, but can't because of the wrong time?

johnpoz

Your time is WAY off - says its March 4th ??

Put in an IP or 3 vs trying to resolve.. Or turn off dnssec until your time is correct

time-a-g.nist.gov 	129.6.15.28 	NIST, Gaithersburg, Maryland 	All services available
time-b-g.nist.gov 	129.6.15.29 	NIST, Gaithersburg, Maryland 	All services available
time-c-g.nist.gov 	129.6.15.30 	NIST, Gaithersburg, Maryland 	All services available
time-d-g.nist.gov 	129.6.15.27 	NIST, Gaithersburg, Maryland 	All services available
time-d-g.nist.gov 	2610:20:6f15:15::27 	NIST, Gaithersburg, Maryland 	All services via IPV6
time-e-g.nist.gov 	129.6.15.26 	NIST, Gaithersburg, Maryland 	All services available
time-e-g.nist.gov 	2610:20:6f15:15::26 	NIST, Gaithersburg, Maryland 	All services via IPv6
time-a-wwv.nist.gov 	132.163.97.1 	WWV, Fort Collins, Colorado 	All services available
time-b-wwv.nist.gov 	132.163.97.2 	WWV, Fort Collins, Colorado 	All services available
time-c-wwv.nist.gov 	132.163.97.3 	WWV, Fort Collins, Colorado 	All services available
time-d-wwv.nist.gov 	132.163.97.4 	WWV, Fort Collins, Colorado 	All services available
time-d-wwv.nist.gov 	2610:20:6f97:97::4 	WWV, Fort Collins, Colorado 	All services via IPv6
time-e-wwv.nist.gov 	132.163.97.6 	WWV, Fort Collins, Colorado 	All services available
time-e-wwv.nist.gov 	2610:20:6f97:97::6 	WWV, Fort Collins, Colorado 	new server, services via IPV6
time-a-b.nist.gov 	132.163.96.1 	NIST, Boulder, Colorado 	All services available
time-b-b.nist.gov 	132.163.96.2 	NIST, Boulder, Colorado 	All services available
time-c-b.nist.gov 	132.163.96.3 	NIST, Boulder, Colorado 	All services available
time-d-b.nist.gov 	132.163.96.4 	NIST, Boulder, Colorado 	All services available
time-d-b.nist.gov 	2610:20:6f96:96::4 	NIST, Boulder, Colorado 	All services available
time-e-b.nist.gov 	132.163.96.6 	NIST, Boulder Colorado 	All services available
time-e-b.nist.gov 	2610:20:6f96:96::6 	NIST, Boulder, Colorado 	All services available
time.nist.gov 	global address for all servers 	Multiple locations 	All services available
utcnist.colorado.edu 	128.138.140.44 	University of Colorado, Boulder 	All services available
utcnist2.colorado.edu 	128.138.141.172 	University of Colorado, Boulder 	All services available

jimp

Yep, that would do it.

Disable DNSSEC, restart NTP, wait a bit and see if the clock is correct, then enable DNSSEC again.

You could also kill ntpd and run something like ntpdate x.x.x.x where x.x.x.x is the IP address of a known good NTP server. Once it skews the clock back to current you can restart unbound and ntpd.

Gertjan

Is is not a time issue, but you proving that resolving (on pfSense !) doesn't work :

So 'NTP' can't do it's work, which is ........ set the clock straight.

Apply the golden rule : when you install a system - what ever the system is : check the clock.
Never take the state of the on battery for granted ; Batteries dies. They are designed to do so.

This :

is your"'case closed" ;)
( except if the screen shot was taken on March, 4 .... )

In the BIOS, set the clock, and do a clean reboot. Go back in the BIOS right away, and check the clock. Change batteries if needed.
As soon as the (initial - hardware) time is ok, pfSense => Resolver => DNSSEC will behave correctly.
And NTP can do it's job.

edit : jimp nailed it.

jimp

@gertjan said in Out of the box install, DNS broken (DNSSEC?):

Is is not a time issue, but you proving that resolving (on pfSense !) doesn't work.

It is a time issue. DNSSEC fails because it can't validate DNSSEC due to the time being so far off.

In the BIOS, set the clock, and do a clean reboot. Go back in the BIOS right away, and check the clock. Change batteries if needed.
As soon as the (initial - hardware) time is ok, pfSense => Resolver => DNSSEC will behave correctly.
And NTP can do it's job.

You could also set the clock to a close value by hand from a command prompt on the firewall:

date [[[[[cc]yy]mm]dd]HH]MM[.ss]] so for 2020, Dec 15th at 09:38 and 30 seconds:
date 202012150938.30

DaddyGo

@gertjan said in Out of the box install, DNS broken (DNSSEC?):

DNSSEC will behave correctly. (sorry :-))

this is the solution...

hhmm considering these:
https://dnssec.vs.uni-due.de/

I don't even understand what their problem is to others with the clock... easy...
so in this world everything is determined by this, just think of (stock market, banks, IT)

Gertjan

@jimp said in Out of the box install, DNS broken (DNSSEC?):

Is is not a time issue,

Conflict between my fingers and the head.
I guess I wanted to start my phrase with "If it is not the time ....." and got de synced while capturing.
Wanted to show with the first image - the NTP server (pool) host name not resolving, and the second image, the date/hour completely wrong, that something is wrong.

DaddyGo

@gertjan said in Out of the box install, DNS broken (DNSSEC?):

Conflict between my fingers and the head.

I don't deny it's right

+++edit:
let me tell you what is the difference, but decide above what will be below

madcatinc

@jimp @johnpoz

Fixed! After all that it was simply the system time that was out (really out). I stopped the NTP service, disabled DNSSEC, updated the time with the command line "ntpdate <random server>", restarted the NTP service, turned back on DNSSEC and everything is working as it should. So happy!

I'm glad I stuck with it, and thank you so much for the help. I learned a lot about DNS along the way, and some new commands to make sure it is all working correctly. Thanks for the help, much appreciated.

johnpoz

@madcatinc Glad you got it sorted. That was as great catch by @jimp on the time being an issue with dnssec..

I normally just assume that time would be correct ;) I mean who doesn't make sure their time is correct? ;)

Would of prob taken quite a bit longer to find your issue if jim hadn't chimed in..