DNS Resolver doesn't work with my university domain.
-
Hey, I'm back here to ask a DNS question.
I've giving DNS Resolver a shot again but while it works for a almost everything, it fails to others.What I would like to do:
Use only DNS Resolver, never query any online DNS server.
So what I did, removed every DNS server from [System/General Setup] and
DNS Resolution Behavior to Use local DNS (127.0.0.1), ignore remote DNS Servers.On DNS Resolver I have Enable DNSSEC Support and Enable Python Module.
And DNS Query Forwarding unchecked.My university site is ufscar.br
Under[ Firewall / pfBlockerNG / Log Browser ] and unified.log I see this:DNS-reply,Sep 5 13:10:44,resolver,DNSKEY,DNSKEY,3600,ufscar.br,127.0.0.1,DNSSEC,unk DNS-reply,Sep 5 13:10:44,resolver,DNSKEY,DNSKEY,3600,ufscar.br,127.0.0.1,DNSSEC,unk DNS-reply,Sep 5 13:10:44,reply,A,CNAME,300,safebrowsing.google.com,10.27.33.140,142.251.129.46,US DNS-reply,Sep 5 13:10:45,resolver,DNSKEY,DNSKEY,3599,ufscar.br,127.0.0.1,DNSSEC,unk DNS-reply,Sep 5 13:10:45,resolver,DNSKEY,DNSKEY,3600,ufscar.br,127.0.0.1,DNSSEC,unk DNS-reply,Sep 5 13:10:45,resolver,DNSKEY,DNSKEY,3600,ufscar.br,127.0.0.1,DNSSEC,unk DNS-reply,Sep 5 13:10:45,resolver,DNSKEY,DNSKEY,3600,ufscar.br,127.0.0.1,DNSSEC,unk DNS-reply,Sep 5 13:10:45,resolver,DNSKEY,DNSKEY,Unk,ufscar.br,127.0.0.1,ServFail,unk DNS-reply,Sep 5 13:10:46,resolver,DNSKEY,DNSKEY,Unk,ufscar.br,127.0.0.1,ServFail,unk DNS-reply,Sep 5 13:10:47,resolver,DNSKEY,DNSKEY,Unk,ufscar.br,127.0.0.1,ServFail,unk DNS-reply,Sep 5 13:10:48,resolver,DNSKEY,DNSKEY,Unk,ufscar.br,127.0.0.1,ServFail,unk DNS-reply,Sep 5 13:10:48,reply,A,CNAME,60,www.linguasagem.ufscar.br,10.27.33.140,200.136.207.102,BR DNS-reply,Sep 5 13:10:48,servfail,A,CNAME,60,www.linguasagem.ufscar.br,10.27.33.140,200.136.207.102,BR DNS-reply,Sep 5 13:10:48,servfail,A,CNAME,60,www.linguasagem.ufscar.br,10.27.33.140,200.136.207.102,BR DNS-reply,Sep 5 13:10:50,servfail,A,CNAME,60,www.linguasagem.ufscar.br,10.27.33.140,200.136.207.102,BR DNS-reply,Sep 5 13:10:50,servfail,A,CNAME,60,www.linguasagem.ufscar.br,10.27.33.140,200.136.207.102,BR DNS-reply,Sep 5 13:10:51,servfail,A,Unknown,1662383510,www.linguasagem.ufscar.br,10.27.33.140,200.136.207.102,BR DNS-reply,Sep 5 13:10:56,servfail,A,Unknown,1662383510,www.linguasagem.ufscar.br,10.27.33.140,200.136.207.102,BR DNS-reply,Sep 5 13:11:34,cache,A,A,894,ufscar.com.br,10.27.33.140,NXDOMAIN,unk DNS-reply,Sep 5 13:11:37,cache,A,A,891,ufscar.com.br,10.27.33.140,NXDOMAIN,unk DNS-reply,Sep 5 13:11:37,reply,SOA,SOA,Unk,ufscar.com.br,10.27.33.140,SOA,unkAny advice on this? Please?
-
@fandangos I am not showing any issues resolving that
; <<>> DiG 9.16.32 <<>> @192.168.9.253 ufscar.br ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ufscar.br. IN A ;; ANSWER SECTION: ufscar.br. 14400 IN A 200.136.207.122 ;; Query time: 244 msec ;; SERVER: 192.168.9.253#53(192.168.9.253) ;; WHEN: Mon Sep 05 12:06:12 Central Daylight Time 2022 ;; MSG SIZE rcvd: 54And the site loads just fine..
-
Yes, the site loads fine it's something on my setup, I'm trying to figure out what am I doing wrong.
-
@fandangos said in DNS Resolver doesn't work with my university domain.:
Yes, the site loads fine it's something on my setup, I'm trying to figure out what am I doing wrong.
You have, in my opinion, too many active variables and they will hinder your troubleshooting effort.
Try first with the plain vanilla DNS Resolver setup. Turn off Python Mode and even consider removing pfBlockerNG-devel for now. Both of those monkey quite a bit with the DNS Resolver setup (Python Mode and pfBlockerNG-devel). So start with just DNS Resolver with the out-of-the-box settings.
For an even simpler setup, consider temporarily turning off DNSSEC as well.
To be sure everything is reset, I would reboot the pfSense firewall. When it comes back up, see if you can resolve the domain directly using the option under the DIAGNOSTICS menu.
If that works, then add things back one at the time to see what breaks it for you. So if you disabled DNSSEC, add it back. If the lookup still works, then reinstall pfBlockerNG-devel. See if the lookup still works. Then finally enable Python Mode and try again. Hopefully during this process you will identify something that breaks it. That then narrows down where to troubleshoot.
Also, what is your hardware (a Netgate appliance perhaps)? What version of pfSense or pfSense Plus are you running? There is a weird intermittent bug in the
unboundversion that is packaged with the 22.05 pfSense Plus release. -
removed pfBlockerNG-devel, disabled python.
Went into System / General Setup, removed all DNS servers and set use local DNS only, ignore remote.
Disabled DNS Query Forwarding in DNS Resolver.
Because that's the way I want it to work.Rebooted my PC with Pfsense.
I'm running a small BGA Intel board with 2.6.0-RELEASE.Went into DNS lookup and search for ufscar.br and :
Host "ufscar.br" could not be resolved.If I look for google.com it will give a result in 60ms
Result Record type
142.250.219.46 A
2800:3f0:4001:822::200e AAAAlike so.
Not sure what else to try.
-
@fandangos if your trying to resolve and failing.. do a dig +trace.. any cnames you would have to follow by hand to see where unbound is failing to resolve.
Quite often its an issue talking to NS somewhere in the chain..
example here is from my pfsense
[22.05-RELEASE][admin@sg4860.local.lan]/root: dig ufscar.br +trace ; <<>> DiG 9.16.26 <<>> ufscar.br +trace ;; global options: +cmd . 37823 IN NS g.root-servers.net. . 37823 IN NS h.root-servers.net. . 37823 IN NS i.root-servers.net. . 37823 IN NS j.root-servers.net. . 37823 IN NS k.root-servers.net. . 37823 IN NS l.root-servers.net. . 37823 IN NS m.root-servers.net. . 37823 IN NS a.root-servers.net. . 37823 IN NS b.root-servers.net. . 37823 IN NS c.root-servers.net. . 37823 IN NS d.root-servers.net. . 37823 IN NS e.root-servers.net. . 37823 IN NS f.root-servers.net. . 37823 IN RRSIG NS 8 0 518400 20220918170000 20220905160000 20826 . Pj2JInC7Khd7BzY2jV37xHvENb3SOdvRwn3uHmZ5C5RhE+Q6AO/1LdH8 4faM0B3nmsvDZgvLFT8JXtBl6dB6tYiKfYOlUuW/pIFGfXIJfUDI4xKJ 283wITPjMfM6xejeuTCUwtRsWfF6F171QKdwek5Y9J7bRzBFllNxylfl 6WOEVmnZdnlo/iS3qbqz2v882KUpeMPeoPqcSTiE7+0ANGxz3IF9aVrm U3OZVEjCV6Zx1Md7bYAfu/62B3Ilu0wlD8797JscrtxueoLt/Qsa6QJ3 1xvMBlSe9RtsZu2wy/Tbeb0wZx0RvR5CkkpwWYduYz5DC1uZr4e3uwDQ R2wGqg== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms br. 172800 IN NS a.dns.br. br. 172800 IN NS b.dns.br. br. 172800 IN NS c.dns.br. br. 172800 IN NS d.dns.br. br. 172800 IN NS e.dns.br. br. 172800 IN NS f.dns.br. br. 86400 IN DS 2471 13 2 5E4F35998B8F909557FA119C4CBFDCA2D660A26F069EF006B403758A 07D1A2E4 br. 86400 IN RRSIG DS 8 1 86400 20220919050000 20220906040000 20826 . LYCKl//tGrWDYY66d2U+I7pIcJdL/TPiR1TiK6EL3G4Uo4okZEx/J/Su iERyk/zuPzl6ybKW7RfqWRjk9KxBw68jEZY4n+FSBRgDSBno55VSeC5O kGhEI68BX2V6Xt6XYmz/MmbfG2aq4IJ4lDNgnbouE8p8J0l1pxVipcJ0 Sx5+efcTlWt5TXpUcledJKd4LrkIyA7pIj+Eu4JFdIeUromIvCI9UeZ3 4YpPu/z8idCydYVQXpkfJelYM3pzQi6ciAzkNLHcDt3Fw11EGq4WuEUC JzoN8pOWKTKt09O6s3pXuyxmsOsB9gHP3kmVfPFU7SOyNAMhbhzx6Wiq nPj4Tg== ;; Received 737 bytes from 199.7.91.13#53(d.root-servers.net) in 32 ms ufscar.br. 3600 IN NS ns-467.awsdns-58.com. ufscar.br. 3600 IN NS ns-1946.awsdns-51.co.uk. ufscar.br. 3600 IN NS ns-1501.awsdns-59.org. ufscar.br. 3600 IN NS ns-531.awsdns-02.net. ufscar.br. 3600 IN DS 26184 13 2 21CA2F8D54DECD6E41A6EC47957C10029AB6D6A670D31D9E3D0F2791 83D7AAAE ufscar.br. 3600 IN RRSIG DS 13 2 3600 20220919121008 20220905111008 65267 br. equEtuASx+Ulcjtez8+5tBJXIOmJ6FBD3KJuGJ2Y+0Z1n/ddMkW3pgsR sTvKz57Xyr+A/hnts5EPPgiU9MVKfQ== ;; Received 352 bytes from 200.189.41.10#53(b.dns.br) in 109 ms ufscar.br. 14400 IN A 200.136.207.122 ufscar.br. 14400 IN RRSIG A 13 2 14400 20220906135225 20220906075225 6215 ufscar.br. rxcqTh2PviB1ew9v7h9bbls3vewwR1tYdDVqlhLaPhd58FjBZiCpWgcH KX/2nqxk9WpVXQdJv8MNTvylPChNog== ;; Received 159 bytes from 2600:9000:5302:1300::1#53(ns-531.awsdns-02.net) in 55 ms [22.05-RELEASE][admin@sg4860.local.lan]/root:I show nothing wrong with dnssec on this domain, but did you try turning off dnssec? dnssec can fail if anything funny is going on with dns interception. Seeing if works with dnssec off could lead us to other paths to follow in troubleshooting the actual problem.
But first thing would like to see is how your +trace looks.
-
[2.6.0-RELEASE][admin@pfSense.home.arpa]/root: dig ufscar.br +trace ; <<>> DiG 9.16.23 <<>> ufscar.br +trace ;; global options: +cmd . 85235 IN NS h.root-servers.net. . 85235 IN NS e.root-servers.net. . 85235 IN NS k.root-servers.net. . 85235 IN NS i.root-servers.net. . 85235 IN NS g.root-servers.net. . 85235 IN NS m.root-servers.net. . 85235 IN NS d.root-servers.net. . 85235 IN NS a.root-servers.net. . 85235 IN NS j.root-servers.net. . 85235 IN NS b.root-servers.net. . 85235 IN NS f.root-servers.net. . 85235 IN NS c.root-servers.net. . 85235 IN NS l.root-servers.net. . 85235 IN RRSIG NS 8 0 518400 20220919050000 20220906040000 20826 . Hx5LBSTiDo3WZuqW/D0FLRM8ATgzAv+gwpQ353b0q566Vkeg367wNdWO oey2OeTl8yQGcKFR2Pr5JlgzKrUMqmvzavCQ/XTGJFVKhVJPlyf2aTYt lTHRYDIL6ZDlGWcunwM3D+q182+HqTSGRu0lY0LU38ObcTjTJut632Wo HJBpq4VhrNhoE08GGn9gOYniOvf6Sltd2aCmVuyvKZpLrcsenEp5vrCn KYAlFK4ZpIWfgliVcdJ9aGHftU6XxjUgim9znlKAfBWZZBpB0nBDE6Sn +m9B1MVB7bysMrDPne95Ysa0mEav7nj8TXx5DJDY9zY5roxySFCWEXR3 9Xf06w== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms br. 172800 IN NS b.dns.br. br. 172800 IN NS c.dns.br. br. 172800 IN NS f.dns.br. br. 172800 IN NS e.dns.br. br. 172800 IN NS a.dns.br. br. 172800 IN NS d.dns.br. br. 86400 IN DS 2471 13 2 5E4F35998B8F909557FA119C4CBFDCA2D660A26F069EF006B403758A 07D1A2E4 br. 86400 IN RRSIG DS 8 1 86400 20220919050000 20220906040000 20826 . LYCKl//tGrWDYY66d2U+I7pIcJdL/TPiR1TiK6EL3G4Uo4okZEx/J/Su iERyk/zuPzl6ybKW7RfqWRjk9KxBw68jEZY4n+FSBRgDSBno55VSeC5O kGhEI68BX2V6Xt6XYmz/MmbfG2aq4IJ4lDNgnbouE8p8J0l1pxVipcJ0 Sx5+efcTlWt5TXpUcledJKd4LrkIyA7pIj+Eu4JFdIeUromIvCI9UeZ3 4YpPu/z8idCydYVQXpkfJelYM3pzQi6ciAzkNLHcDt3Fw11EGq4WuEUC JzoN8pOWKTKt09O6s3pXuyxmsOsB9gHP3kmVfPFU7SOyNAMhbhzx6Wiq nPj4Tg== ;; Received 767 bytes from 192.112.36.4#53(g.root-servers.net) in 154 ms ufscar.br. 3600 IN NS ns-1946.awsdns-51.co.uk. ufscar.br. 3600 IN NS ns-1501.awsdns-59.org. ufscar.br. 3600 IN NS ns-531.awsdns-02.net. ufscar.br. 3600 IN NS ns-467.awsdns-58.com. ufscar.br. 3600 IN DS 26184 13 2 21CA2F8D54DECD6E41A6EC47957C10029AB6D6A670D31D9E3D0F2791 83D7AAAE ufscar.br. 3600 IN RRSIG DS 13 2 3600 20220919121008 20220905111008 65267 br. equEtuASx+Ulcjtez8+5tBJXIOmJ6FBD3KJuGJ2Y+0Z1n/ddMkW3pgsR sTvKz57Xyr+A/hnts5EPPgiU9MVKfQ== ;; Received 352 bytes from 200.219.154.10#53(d.dns.br) in 10 ms ufscar.br. 14400 IN A 200.136.207.122 ufscar.br. 14400 IN RRSIG A 13 2 14400 20220906140123 20220906080123 6215 ufscar.br. LIxJVgb/NVcw405NqqIlrDDyCnMRtgNQj15zgT1hTDNNXDVpSby6+YeM D0v5xUqubr1ficqy7FsX+aQeuPpb2g== ;; Received 159 bytes from 205.251.193.211#53(ns-467.awsdns-58.com) in 37 ms [2.6.0-RELEASE][admin@pfSense.home.arpa]/root: ping ufscar.br ping: cannot resolve ufscar.br: Host name lookup failureLooks similar to yours.
Not sure if this makes any difference but I have Block private networks and loopback addresses and Block bogon networks under my WAN setup.
-
@fandangos well clearly you can resolve it, via your trace.
But your not pointing pfsense to itself for dns? Or unbound isn't running or is failing?
So www.google.com works? Can we see the output of say dig www.google.com from your pfsense cmd line, or the gui dns lookup tool.
-
I disabled DNSSEC and voilá!
[2.6.0-RELEASE][admin@pfSense.home.arpa]/root: dig ufscar.br +trace ; <<>> DiG 9.16.23 <<>> ufscar.br +trace ;; global options: +cmd . 86400 IN NS e.root-servers.net. . 86400 IN NS f.root-servers.net. . 86400 IN NS d.root-servers.net. . 86400 IN NS c.root-servers.net. . 86400 IN NS a.root-servers.net. . 86400 IN NS k.root-servers.net. . 86400 IN NS l.root-servers.net. . 86400 IN NS j.root-servers.net. . 86400 IN NS m.root-servers.net. . 86400 IN NS h.root-servers.net. . 86400 IN NS i.root-servers.net. . 86400 IN NS g.root-servers.net. . 86400 IN NS b.root-servers.net. . 86400 IN RRSIG NS 8 0 518400 20220919050000 20220906040000 20826 . Hx5LBSTiDo3WZuqW/D0FLRM8ATgzAv+gwpQ353b0q566Vkeg367wNdWO oey2OeTl8yQGcKFR2Pr5JlgzKrUMqmvzavCQ/XTGJFVKhVJPlyf2aTYt lTHRYDIL6ZDlGWcunwM3D+q182+HqTSGRu0lY0LU38ObcTjTJut632Wo HJBpq4VhrNhoE08GGn9gOYniOvf6Sltd2aCmVuyvKZpLrcsenEp5vrCn KYAlFK4ZpIWfgliVcdJ9aGHftU6XxjUgim9znlKAfBWZZBpB0nBDE6Sn +m9B1MVB7bysMrDPne95Ysa0mEav7nj8TXx5DJDY9zY5roxySFCWEXR3 9Xf06w== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 695 ms br. 172800 IN NS a.dns.br. br. 172800 IN NS b.dns.br. br. 172800 IN NS c.dns.br. br. 172800 IN NS d.dns.br. br. 172800 IN NS e.dns.br. br. 172800 IN NS f.dns.br. br. 86400 IN DS 2471 13 2 5E4F35998B8F909557FA119C4CBFDCA2D660A26F069EF006B403758A 07D1A2E4 br. 86400 IN RRSIG DS 8 1 86400 20220919050000 20220906040000 20826 . LYCKl//tGrWDYY66d2U+I7pIcJdL/TPiR1TiK6EL3G4Uo4okZEx/J/Su iERyk/zuPzl6ybKW7RfqWRjk9KxBw68jEZY4n+FSBRgDSBno55VSeC5O kGhEI68BX2V6Xt6XYmz/MmbfG2aq4IJ4lDNgnbouE8p8J0l1pxVipcJ0 Sx5+efcTlWt5TXpUcledJKd4LrkIyA7pIj+Eu4JFdIeUromIvCI9UeZ3 4YpPu/z8idCydYVQXpkfJelYM3pzQi6ciAzkNLHcDt3Fw11EGq4WuEUC JzoN8pOWKTKt09O6s3pXuyxmsOsB9gHP3kmVfPFU7SOyNAMhbhzx6Wiq nPj4Tg== ;; Received 765 bytes from 199.9.14.201#53(b.root-servers.net) in 121 ms ufscar.br. 3600 IN NS ns-1946.awsdns-51.co.uk. ufscar.br. 3600 IN NS ns-467.awsdns-58.com. ufscar.br. 3600 IN NS ns-531.awsdns-02.net. ufscar.br. 3600 IN NS ns-1501.awsdns-59.org. ufscar.br. 3600 IN DS 26184 13 2 21CA2F8D54DECD6E41A6EC47957C10029AB6D6A670D31D9E3D0F2791 83D7AAAE ufscar.br. 3600 IN RRSIG DS 13 2 3600 20220919121008 20220905111008 65267 br. equEtuASx+Ulcjtez8+5tBJXIOmJ6FBD3KJuGJ2Y+0Z1n/ddMkW3pgsR sTvKz57Xyr+A/hnts5EPPgiU9MVKfQ== ;; Received 352 bytes from 200.229.248.10#53(e.dns.br) in 10 ms ufscar.br. 14400 IN A 200.136.207.122 ufscar.br. 14400 IN RRSIG A 13 2 14400 20220906140638 20220906080638 6215 ufscar.br. oFYAjIlBisxx/2ZeOicEdyazuDxqxNpNE8VYH4FklBYokaoZp4uZMXXA AMJDViJxz7u/eEZqUUN6+12gxn5OSw== ;; Received 159 bytes from 205.251.199.154#53(ns-1946.awsdns-51.co.uk) in 9 ms [2.6.0-RELEASE][admin@pfSense.home.arpa]/root: ping ufscar.br PING ufscar.br (200.136.207.122): 56 data bytes 64 bytes from 200.136.207.122: icmp_seq=0 ttl=55 time=17.377 ms 64 bytes from 200.136.207.122: icmp_seq=1 ttl=55 time=17.592 ms 64 bytes from 200.136.207.122: icmp_seq=2 ttl=55 time=17.514 ms ^C --- ufscar.br ping statistics --- 4 packets transmitted, 3 packets received, 25.0% packet loss round-trip min/avg/max/stddev = 17.377/17.494/17.592/0.089 mswhile now it works what do you mean by pointing pfsense to itself for DNS?
And one thing I'm noticing while browsing, when accessing a site for the first time it's really slow, images take a long time to load and the site fails the first time loading.
-
@fandangos need to figure out why dnssec is failing.. I show it all good via online testing, and I am not having any problems doing dnssec for it
https://dnssec-debugger.verisignlabs.com/ufscar.br
https://dnsviz.net/d/ufscar.br/dnssec/
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
I think I solved the DNS Resolver slowness by increasing Outgoing TCP Buffers and Incoming TCP Buffers to 50, plus Number of Queries per Thread to 2048 but what made it faster was enable Prefetch Support and Prefetch DNS Key Support.
But enabling DNSSEC kills the access to ufscar.br indeed.
Looking at reddit:
https://www.reddit.com/r/PFSENSE/comments/vuhcni/dnssec_broken_recently/"It's always been broken for me on CE 2.6. You probably just started noticing it with certain websites."
Could it be a Pfsense 2.6 issue?
-
@fandangos let me fire up my 2.6 vm and query that domain. But seems unlikely.. I am running 22.05 and there is a difference in the unbound between them..
BRB..
Ok I fired up my 2.6 VM of pfsense, not having any issues with that domain with dnssec enable and resolving.
To validate dnssec is being used, I queried for 2 known bad fail validation fqdn.. And both of them fail..
So clearly its not a specific hey that domain doesn't work in 2.6 or that dnssec doesn't work in 2.6..
Your issue "could be" something as nefarious as some sort of dns interception breaking dnssec.. I stress "could be"! But more likely than not it could just be an issue with geographic location and what NS your hitting and an issue with with dnssec.. But 2 different dnssec sites show nothing wrong with dnssec for that fqdn.
Have to dig a bit deeper to find out what is causing the problem..
edit2: here is a quick and simple test for interception.. Do a directed query to say 1.2.3.4 for something like www.google.com.. that should just time out, if you get a answer - then your isp is doing some very blatant dns interception
[22.05-RELEASE][admin@sg4860.local.lan]/root: dig @1.2.3.4 www.google.com ; <<>> DiG 9.16.26 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached [22.05-RELEASE][admin@sg4860.local.lan]/root:edit3: can we test for dnssec working on other sites... Its possible maybe this is the only site you have run into that is actually dnssec..
So if you query
sigok.verteiltesysteme.netYou should get back an IP.. If you query
sigfail.verteiltesysteme.net
It should give back servfail if you have dnssec enabled.
You can also just go like here, do you get a thumbs up that your using dnssec when you have it enabled?
-
Ok
[2.6.0-RELEASE][admin@pfSense.home.arpa]/root: dig @1.2.3.4 www.google.com ; <<>> DiG 9.16.23 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached [2.6.0-RELEASE][admin@pfSense.home.arpa]/root: dig @1.2.3.4 www.google.com ; <<>> DiG 9.16.23 <<>> @1.2.3.4 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reachedwithout and with DNSSEC.
[2.6.0-RELEASE][admin@pfSense.home.arpa]/root: dig sigok.verteiltesysteme.net ; <<>> DiG 9.16.23 <<>> sigok.verteiltesysteme.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40230 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;sigok.verteiltesysteme.net. IN A ;; ANSWER SECTION: sigok.verteiltesysteme.net. 17 IN A 134.91.78.139 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 06 07:24:06 GMT 2022 ;; MSG SIZE rcvd: 71 [2.6.0-RELEASE][admin@pfSense.home.arpa]/root: dig sigfail.verteiltesysteme.net ; <<>> DiG 9.16.23 <<>> sigfail.verteiltesysteme.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51731 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;sigfail.verteiltesysteme.net. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 06 07:24:21 GMT 2022 ;; MSG SIZE rcvd: 57but ufscar.br
[2.6.0-RELEASE][admin@pfSense.home.arpa]/root: dig ufscar.br ; <<>> DiG 9.16.23 <<>> ufscar.br ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6332 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;ufscar.br. IN A ;; Query time: 1159 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 06 07:25:11 GMT 2022 ;; MSG SIZE rcvd: 38Servfail.
The thing is, this is mine and my wife's university website, it's not something I can just stop using it so the solution would be just disabling DNSSEC for now?It looks like some problem beyond my setup from all the tests we did so far.
-
@fandangos well the simple solution sure would just be turn off dnssec, but other option for specific domains that you need to get to, but for reason can not determine yet dnssec is failing.
A way to allow access to that domain, and still use dnssec for other domains would be setting
domain-insecure:
In your advanced options box..
so for example you see how sigfail.verteiltesysteme.net fails.. if I set that fqdn as domain-insecure it doesn't do dnssec on it and now get back an IP
This should allow you to get to your website, but still be doing dnssec for other sites - and work around until you can figure out what is causing the problem.
btw does for example www.ufscar.br work?
;; QUESTION SECTION: ;www.ufscar.br. IN A ;; ANSWER SECTION: www.ufscar.br. 14400 IN CNAME web-07-nova.ufscar.br. web-07-nova.ufscar.br. 14400 IN A 200.136.207.122 -
@fandangos said in DNS Resolver doesn't work with my university domain.:
removed pfBlockerNG-devel, disabled python.
Went into System / General Setup, removed all DNS servers and set use local DNS only, ignore remote.
Disabled DNS Query Forwarding in DNS Resolver.
Because that's the way I want it to work.Rebooted my PC with Pfsense.
I'm running a small BGA Intel board with 2.6.0-RELEASE.Went into DNS lookup and search for ufscar.br and :
Host "ufscar.br" could not be resolved.If I look for google.com it will give a result in 60ms
Result Record type
142.250.219.46 A
2800:3f0:4001:822::200e AAAAlike so.
Not sure what else to try.
@johnpoz is the resident DNS expert here, so you are in good hands troubleshooting with his assistance.
Reading the threads above I see that the problem has at least been isolated down to DNSSEC. In the beginning there were three possibilities: (1) DNSSEC; (2) pfBlockerNG-devel; and (3) Python Mode with
unbound. By eliminating options and testing with a vanilla setup you eventually found DNSSEC as the apparent problem. Now you can concentrate efforts to figuring out why that option is failing. -
@johnpoz said in DNS Resolver doesn't work with my university domain.:
@fandangos need to figure out why dnssec is failing.. I show it all good via online testing, and I am not having any problems doing dnssec for it
https://dnssec-debugger.verisignlabs.com/ufscar.br
https://dnsviz.net/d/ufscar.br/dnssec/
I saw the same thing : these two looks good.
I refreshed the latest scan on dnssec-debugger.verisignlabs.com - still all ok.But : I did a zonemaster.net scan :
https://www.zonemaster.net/result/e74f48762d19101d
and that looks messy ....I count about twenty "DNSKEY tags", so the zone size must be ... huge.
Something is definitely not ok.
The domain name admin is playing with zone ZSK resigning ? ( and oh boy, he fails ).If "ufscar.br" is DNSSEC singed, and it is, and DNSSEC verification fails, then all is well : "no answer" is the good answer.
-
@bmeeks yeah could take a bit of digging to figure out why dnssec is failing, if its working for other sites, it doesn't make a lot of sense
But maybe its not really working all that well on all other sites??
@Fandangos maybe you should check that the time and timezone are correct or at least close to being correct..
The RRSIG has a 2 times there, you have to be within that time frame etc.. Or dnssec would fail one is the Expiration the other is Inception of that signature.
It could get really tricky because different NS could use say a wider range of when the signature is good, and if your time is not off too much site A works, but if maybe site B has smaller window of the time of the signature.. So it fails..
edit: Looking at the report @Gertjan linked too - this warning jumps out at me
"RRSIG with keytag 26184 and covering type(s) DNSKEY has a remaining validity of 17732 seconds, which is too short. "
So if they are using really short validity ranges and time is off on pfsense that could explain the problem..
-
This time situation is always problematic. I have a unraid NAS running here that suffers the same problem.
I live near São Paulo (the city) within São Paulo the state.
If I select America/Sao Paulo using 2.pfsense.pool.ntp.org the time is wrong by 3 hours (minus 3 hours).
Right now is 12:00 and it shows 9:00 AM.
I have the same behavior on my NAS using Unraid that uses another ntp pool.So to get the right time I have to use ETC/GMT+0 which, looking at the clock on my phone that register with the cell towers and services it is 4 minutes behind.
So that might be the problem. There's no correct time zone to be selected and the one that is closer is 4 minutes behind.
But.. 17732 is 289 minutes, so it's not it but it would be good to actually fix the ntp situation, I've never found a solution for this.
EDIT:
Even using 0.br.pool.ntp.org server in Brazil follows the same problem: 3 hours behind with America/Sao_Paulo.EDIT 2:
Looking online the correct time zone for São Paulo is Etc/GMT+3, and this results in the same problem using America/Sao_Paulo, 3 hours behind. It's like if GMT is wrong.Does NTP`pool time uses anything within the BIOS?
ETC/UTC timezone also gives the 4 minutes behind time zone.
-
EDIT wasn't working.
EDIT 3:
https://forum.netgate.com/topic/158490/pfsense-php-time-is-incorrect-in-america-sao_paulo-time-zone/
It seems somebody else saw this and it should have been fixed in 2.5 but it seems it was not. -
@fandangos said in DNS Resolver doesn't work with my university domain.:
There's no correct time zone to be selected and the one that is closer is 4 minutes behind.
Huh that makes zero sense to be honest.. There are no timezones on the planet that I am aware of that are 4 minutes different.. That would be insane..
I know of some that are 30 minutes, and some that are 45 minutes, and I believe there is one that has 15 minute difference other than just the 0 hour differences..
Clearly you have something wrong with time.. But 4 minutes? That seems insane..
So looking up the timezone for São Paulo, and my time zone CDT, and looking on my phone, everything is pretty much dead nuts on for correct time.
edit: doesn't really matter what zone name you use be it +1, -3 etc.. Worse case is switch from Standard to Daylight savings could be off if zone your actually in is different than the zone you choose. But I am lost to a 4 minute difference - that should never be the case no matter what zone your in, other than just the clock being off and not in sync with a ntp server.
