DNS periodic failure - with pfblocker installed.
-
Only without pfblocker, but that is not diagnostic, but only indicative as I have the same install in two other sites with no problems. The installs are new.
-
I decided to include unbound.conf
-
That conf is all messed up... There are repeating copies of the config in it..
This is just a small snipped - there are multiple more copies
########################## # Unbound Configuration ########################## ## # Server configuration ## server: chroot: /var/unbound username: "unbound" directory: "/var/unbound" pidfile: "/var/run/unbound.pid" use-syslog: yes port: 53 verbosity: 1 hide-identity: yes hide-version: yes harden-glue: yes do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes unbound.conf...skipping... ########################## # Unbound Configuration ########################## ## # Server configuration ## server: chroot: /var/unbound username: "unbound" directory: "/var/unbound" pidfile: "/var/run/unbound.pid" use-syslog: yes port: 53 verbosity: 1 hide-identity: yes hide-version: yes harden-glue: yes do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes do-daemonize: yes :...skipping... ########################## # Unbound Configuration ########################## ## # Server configuration ## server: chroot: /var/unbound username: "unbound" directory: "/var/unbound" pidfile: "/var/run/unbound.pid" use-syslog: yes port: 53 verbosity: 1 hide-identity: yes hide-version: yes harden-glue: yes do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes do-daemonize: yes module-config: "validator iterator" :...skipping... ########################## # Unbound Configuration ########################## ## # Server configuration ## server: chroot: /var/unbound username: "unbound" directory: "/var/unbound" pidfile: "/var/run/unbound.pid" use-syslog: yes port: 53 verbosity: 1 hide-identity: yes hide-version: yes harden-glue: yes do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes do-daemonize: yes module-config: "validator iterator" unwanted-reply-threshold: 0 num-queries-per-thread: 512 :...skipping... ########################## # Unbound Configuration ##########################That stuff should only be in there once! For example here is my conf
[2.4.4-RELEASE][admin@sg4860.local.lan]/var/unbound: cat unbound.conf ########################## # Unbound Configuration ########################## ## # Server configuration ## server: chroot: /var/unbound username: "unbound" directory: "/var/unbound" pidfile: "/var/run/unbound.pid" use-syslog: yes port: 53 verbosity: 1 hide-identity: no hide-version: no harden-glue: yes do-ip4: yes do-ip6: yes do-udp: yes do-tcp: yes do-daemonize: yes module-config: "validator iterator" unwanted-reply-threshold: 0 num-queries-per-thread: 512 jostle-timeout: 200 infra-host-ttl: 900 infra-cache-numhosts: 50000 outgoing-num-tcp: 20 incoming-num-tcp: 20 edns-buffer-size: 4096 cache-max-ttl: 86400 cache-min-ttl: 3600 harden-dnssec-stripped: yes msg-cache-size: 50m rrset-cache-size: 100m num-threads: 4 msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 outgoing-range: 4096 #so-rcvbuf: 4m auto-trust-anchor-file: /var/unbound/root.key prefetch: yes prefetch-key: yes use-caps-for-id: yes serve-expired: yes # Statistics # Unbound Statistics statistics-interval: 0 extended-statistics: yes statistics-cumulative: yes # TLS Configuration tls-cert-bundle: "/etc/ssl/cert.pem" # Interface IP(s) to bind to interface: 192.168.3.253 interface: 2001:470:snipped::253 interface: 192.168.9.253 interface: 2001:470:snipped::253 interface: 192.168.2.253 interface: 192.168.6.253 interface: 192.168.4.253 interface: 192.168.7.253 interface: fe80::208:a2ff:fe0c:e624%igb0 interface: 127.0.0.1 interface: ::1 # Outgoing interfaces to be used outgoing-interface: 127.0.0.1 outgoing-interface: ::1 # DNS Rebinding # For DNS Rebinding prevention private-address: 10.0.0.0/8 private-address: ::ffff:a00:0/104 private-address: 172.16.0.0/12 private-address: ::ffff:ac10:0/108 private-address: 169.254.0.0/16 private-address: ::ffff:a9fe:0/112 private-address: 192.168.0.0/16 private-address: ::ffff:c0a8:0/112 private-address: fd00::/8 private-address: fe80::/10 # Access lists include: /var/unbound/access_lists.conf # Static host entries include: /var/unbound/host_entries.conf # dhcp lease entries include: /var/unbound/dhcpleases_entries.conf # Domain overrides include: /var/unbound/domainoverrides.conf # Unbound custom options server: private-domain: "plex.direct" local-zone: "use-application-dns.net" always_nxdomain #so-reuseport: no #log-queries: yes #log-replies: yes #private-address: ::/0 # filters out all AAAA ! ### # Remote Control Config ### include: /var/unbound/remotecontrol.conf [2.4.4-RELEASE][admin@sg4860.local.lan]/var/unbound:I snipped out some ipv6 addresses.
-
Yes, I got that copy with "less" for some reason it repeated. Here is a better copy.
-
So where in the GUI does I allow me to get rid of the IPV6? Must this always be done in unbound.conf?
-
So what exactly are you wanting to stop, you wanting unbound to not use ipv6? But you want pfsense to have ipv6? Why not just turn off IPv6 on pfsense if you don't want unbound to use ipv6.
If you want pfsense to have ipv6, but unbound not to use ipv6 then you would have to turn it off in unbound..
do-ip6: yes
Set that to no..
You can also set pfsense to prefer IPv4, but I don't think that has an effect on unbound? Have not tested such a configuration. My pfsense doesn't have Ipv6 on its wan, and I set unbound to only use wan for outbound.
Oh wait - I had changed it to only use localhost, so it could be doing IPv6 I guess through my tunnel.
-
I am sorry that I did not make this clear. I must forward all DNS requests to the root servers via the checkbox in the Unbound configuration. The normal caching system that Unbound uses is impossibly slow causing frequent loss of service. If I use the pfSense DNS diagnoistic tool it typically will allow three lookups and then there is very high latency or timeouts. The same is true for DIG and NSLOOKUP.
I am thinking that we are having some kind of problem with the ISP. My tech commented that when she tested this all the way back to the modem that it was slow there too. I was running High Availability and wondered if there was some sort of multicast problem flooding the network, but that is not the problem. As I mentioned, when I use a very stripped down system the DNS works. I am wondering if using pfBlocker significantly increases DNS lookups so that the ISPs system is slowing us down. Of course in thinking this I am also thinking the the ISP is intercepting our DNS requests. When I use their DNS I note that one of their two servers is very fast, but one is extremely slow and unreliable. For this reason I did not include their servers in my list, but it seems that Unbound uses its own list and that the ISP could be intercepting those. I had a similar experience with a Hughes setup. I am always learning more about the Internet infrastructure. Now it is time for me to learn more about DNS.
-
Huh?? You can not forward to roots, it doesn't work that way..
You can resolve the NS for the tld, and then from those that the roots hand you can resolve the NS for the domain.. But you can not forward, ie ask for a recursive lookup to authoritative NS..
If your isp does something with dns, or has shitty connections then yeah resolving could be a problem for you.. Its quite possible ISP only want to let you use their NS..
Does your dns work if you forward to them, or say public dns like 8.8.8.8 or opendns or quad9? Cloudflare at 1.1.1.1?
-
Ok, yes I am still dominating the terminology. Exactly, right now the only thing that works is forwarding, Google, OpenDNS, IBM, but according to the documentation I read they are only really forwarders themselves. One of my attachments is the output from
root: unbound-control -c /var/unbound/unbound.conf lookup nbcnews.com.
from the command line of freebsd. It looks to me like the latency is very high.
Yes only forwarding works.
-
What part of the world are you in? Can you post the output and we can take a look, also a dig +trace would be helpful
[2.4.4-RELEASE][admin@sg4860.local.lan]/var/unbound: unbound-control -c /var/unbound/unbound.conf lookup nbcnews.com The following name servers are used for lookup of nbcnews.com. ;rrset 3595 4 2 7 0 nbcnews.com. 3595 IN NS nsa1.nbcnews.com. nbcnews.com. 3595 IN NS nsa2.nbcnews.com. nbcnews.com. 3595 IN NS nsa3.nbcnews.com. nbcnews.com. 3595 IN NS nsa4.nbcnews.com. nbcnews.com. 3595 IN RRSIG NS 7 2 300 20191121080616 20191114080616 16883 nbcnews.com. RgKiUff637dy9NFCh+Z4USUwIXPzdMxauBzGoTonKsbcpFw8Qbm0643hPrJRqwGj9CUlqrMWMeTwVwIZkCYnOhPyi7IB3SlUEV+XnUQXpy3IgliNVvzOzaXs1uGii46/mRT3I7RzV1QD3Va7cTG7LbQNseKEkLsj6+TSgbflXL0= ;{id = 16883} nbcnews.com. 3595 IN RRSIG NS 7 2 300 20191117160613 20191110160613 48137 nbcnews.com. FsoK3GZiCaS4RLUKjXqGhB6BdeN0f0zH4a1/EZDTshxzfWJBevWzRpQ2U7vSwVvCL49RJbv6HarIChU++bdKWpGhjJWQVkhz7sWhSkYXtGuRAATNpoo50Go953ClaVqnZeJUbfvE7r7xVi91nCeGlsLHlyhnqJdtrZhgb1ifjUQ= ;{id = 48137} ;rrset 3595 1 2 8 0 nsa4.nbcnews.com. 3595 IN A 18.191.2.199 nsa4.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191121080616 20191114080616 16883 nbcnews.com. fnSF5uwqgWuglPQmCRoSx08IdvDpiyN7DEQJSFCmp/CnHiTFs/LvJziIMdu70cIGEWDToQOvxSxgKQASwQl6zlCVQofbbV/yifnKsHGm7pCe+FomdXF0lsQ6t39w3Jp3SSU5os22ooerCDFOn5hnMAJfI7vFCvFeHZ8yQSoyIto= ;{id = 16883} nsa4.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191117160612 20191110160612 48137 nbcnews.com. T+FSwGiTteTGxxGG+fQiNiGJjHqs8wQ1KHWpGhUE2QCDNq4D1LFsZtP6QByd0U4qQa8/bxht8PEotn9MFbkSIRy9GHfYk9cEZ9BbotcxRmt+sgQdRSSEDH5Gaf3ChSuVQOHG2kF18tzdypJ4GaXCfLi4RAqwH7RAbEyxSyoeXdY= ;{id = 48137} ;rrset 3595 1 2 8 0 nsa3.nbcnews.com. 3595 IN A 13.52.111.184 nsa3.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191121080617 20191114080617 16883 nbcnews.com. p4tNe8MXLJ3eBbhmWM7txF2sM9gqKJr7Cv2rrqbpJUiFnlSi4xQyyaQiEtOtiJJ1Un8O3mn7jC4ohtMqev5SjSAuI6bdjD8W9TBqCrl4PHM11utxwA7uXzKNR0fvapsNM3/WzR0uJ4wZ9eA+CM+feab96LwG9ugNUtmlLhLQYfs= ;{id = 16883} nsa3.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191117160613 20191110160613 48137 nbcnews.com. QGvvMGgSLT8lF8f13xW1igyvQU95xjcMCY9PvpgjoNU94uvgtsCAKlYdvNoCDyhrhC0jC8JACXYcIaokr60LM1bbRoILM6tVn0hHNJo6ss/Z0lOxOEHFEVK4zqEHGFcidU65yZ9HNtCe8ZEYmbaPVSBMvxuTkH+a83ST7hdbjts= ;{id = 48137} ;rrset 3595 1 2 8 0 nsa2.nbcnews.com. 3595 IN A 54.208.199.200 nsa2.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191120232158 20191113232158 16883 nbcnews.com. gCJRLg+cFOKVVDQY9WTx8WqA9kTgbt0627wqr2ntfBGb6J8rXE4PuiBl5dy5WM9WOtZ2dJNgSNSTUgoQWmew4CPgBs+g1pBsf8kQ8GXFtVV6dsPlpFuXHPHuDbfGRBN7Wz+Ec82+CRFh0kccVKjxgrSKxl28KHeIyMOePWrAig0= ;{id = 16883} nsa2.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191117160612 20191110160612 48137 nbcnews.com. mHKATQkjT/q3n2plfcplNKDxz4l/UaM/NphTGrg/cA38IHFe636svKsLRJnaVZ06lD9SA96lu1RZwlQAC/kHK7Fg4UDIif7Q2jrpQ/n36tYn1XqPJXN1UOW77tiupMvKWr/liAP1JRopu1kaGPQp11T1CHsYllktLOaJKaMrR68= ;{id = 48137} ;rrset 3595 1 2 8 0 nsa1.nbcnews.com. 3595 IN A 54.200.82.65 nsa1.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191121080616 20191114080616 16883 nbcnews.com. LYPu2K2A7GrIAxgFqy7X+u7JYjAopSpaKN3N7lBf5KSV+fgjbLA93yoma7fe1WpqGrb0UBEgtphwFQ4efmfzpOGE2nmItj9njliCjO/S4v1qlXp7n/RKbJN3+TX8lzYpPY556SI9sv1ZHxPV0YfFKjqgmNTjdVvE0200q4ONzLw= ;{id = 16883} nsa1.nbcnews.com. 3595 IN RRSIG A 7 3 300 20191117160613 20191110160613 48137 nbcnews.com. orXDdoInc1g8VYJXL/iNiP6aww3tXOAGJ5SiZ500/Kn6zH/Rwb46aQiMfc502wKTnVk9nUwxNA63m668VkvzKUoZ/OUc/nbOtpJJs307xhOFPXNtygJFt9zLiw6C/1owPQ3XpKlJC4iPEDKvguegEAwKtxSNLwF2KFi/v0+9lmg= ;{id = 48137} Delegation with 4 names, of which 4 can be examined to query further addresses. It provides 4 IP addresses. 54.200.82.65 rto 345 msec, ttl 894, ping 25 var 80 rtt 345, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 54.208.199.200 rto 251 msec, ttl 894, ping 19 var 58 rtt 251, tA 0, tAAAA 0, tother 0, EDNS 0 probed. 13.52.111.184 rto 360 msec, ttl 894, ping 8 var 88 rtt 360, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 18.191.2.199 rto 324 msec, ttl 894, ping 4 var 80 rtt 324, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. [2.4.4-RELEASE][admin@sg4860.local.lan]/var/unbound:Your going to want to do that in resolver mode, not forwarder mode..
Can you do queries directly to one of the NS for that domain
$ dig @nsa1.nbcnews.com nbcnews.com ; <<>> DiG 9.14.7 <<>> @nsa1.nbcnews.com nbcnews.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4094 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nbcnews.com. IN A ;; ANSWER SECTION: nbcnews.com. 180 IN A 35.153.221.86 nbcnews.com. 180 IN A 34.192.145.89 nbcnews.com. 180 IN A 52.10.191.40 nbcnews.com. 180 IN A 52.39.105.74 ;; AUTHORITY SECTION: nbcnews.com. 300 IN NS nsa4.nbcnews.com. nbcnews.com. 300 IN NS nsa1.nbcnews.com. nbcnews.com. 300 IN NS nsa2.nbcnews.com. nbcnews.com. 300 IN NS nsa3.nbcnews.com. ;; ADDITIONAL SECTION: nsa1.nbcnews.com. 300 IN A 54.200.82.65 nsa2.nbcnews.com. 300 IN A 54.208.199.200 nsa3.nbcnews.com. 300 IN A 13.52.111.184 nsa4.nbcnews.com. 300 IN A 18.191.2.199 ;; Query time: 71 msec ;; SERVER: 54.200.82.65#53(54.200.82.65) ;; WHEN: Thu Nov 14 21:18:08 Central Standard Time 2019 ;; MSG SIZE rcvd: 244The TTL on those records are horrifically low.. 180 seconds, and 300 for the NS.. that is just nuts - unless they are in the process of a switch over to new NS.. There is no reason to be that low.. 3 minutes - come on ;)
Can you pick a different thing to check say cnn.com or yahoo.com, etc.
My first lookup, can be a bit misleading, since I set a min ttl of 3600 - because I loath companies that do such low ttls
Doing a +trace will show you exactly how resolving works, and who you talk to in the process.
[2.4.4-RELEASE][admin@sg4860.local.lan]/var/unbound: dig cnn.com +trace ; <<>> DiG 9.12.2-P1 <<>> cnn.com +trace ;; global options: +cmd . 62116 IN NS a.root-servers.net. . 62116 IN NS b.root-servers.net. . 62116 IN NS c.root-servers.net. . 62116 IN NS d.root-servers.net. . 62116 IN NS e.root-servers.net. . 62116 IN NS f.root-servers.net. . 62116 IN NS g.root-servers.net. . 62116 IN NS h.root-servers.net. . 62116 IN NS i.root-servers.net. . 62116 IN NS j.root-servers.net. . 62116 IN NS k.root-servers.net. . 62116 IN NS l.root-servers.net. . 62116 IN NS m.root-servers.net. . 62116 IN RRSIG NS 8 0 518400 20191127170000 20191114160000 22545 . YFNnBkdMGc/6su90veaOS55FRZw4fq8WB/dbhsSzW8NXjeJmRHOBYNrN WDwK3ov+jHRS8NjFmT20OpaDFpKR82IwQluNYMSVDUxHjv4GPjaWbMgF f4S+FGHxY+B9EPc4IIi0Z1DRvyb2z8FKt+Hi0MBNVFKfOJKCvlu14yuz 5d3vFMJA+A7tWN2TFvnrcMrjS3KFv42M8o+XCnNeMfvwqKYA4FpjWx7c Au9yjIrxQWJgRcS5XzTWrJJsq4qDr3exNSLJbCylpkcozZ3KPgzmzK0G GpmqyA0RhTMClWczjgkDV/a1wqOyz2iYwsU0gAUbv29Y7vvxOIhvbrgg EcskUA== ;; 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 l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20191127210000 20191114200000 22545 . R5m8Q0GboykgMZCnL8qO8DbY26k+Zu9f+MrkuxjZXayLnJPmk1FYyRZG Be7oQuQ0UqRf+x4QpdK/bQj0xAumooxDis36gT2YIM8vU5aBLrpFAQHo 3GrxOOlwTWljVY6DMrRJoAjfNnrtYLPKz9IFDuEEvgzXg3SfvAwCekiF CDZzbxotpD6GnvgJARrvgh/IKeBmkiWQ6UcBU1qvHvtN+opz1Zv2Fj9I Egi3sF786vg59uO9swVqMJy5tkmyghdZ4r3uAEhyvdZjvWu3LLjZtZh6 Bpy/uOUj7Jc5z0awIy6je/XLkpGNhoE3ghzZHoHn+zyYox8j4/Go2eyB TUW7vA== ;; Received 1167 bytes from 2001:7fe::53#53(i.root-servers.net) in 67 ms cnn.com. 172800 IN NS ns-47.awsdns-05.com. cnn.com. 172800 IN NS ns-576.awsdns-08.net. cnn.com. 172800 IN NS ns-1630.awsdns-11.co.uk. cnn.com. 172800 IN NS ns-1086.awsdns-07.org. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20191119054905 20191112043905 12163 com. DWeezLYg0WoPrctVhXYCQrY7V3R1Ue6M7Wik02NqCEI1wvkGFPY+C0IZ gQF3yb8KZdoymT4YbWIxoTRn7J13y0q1Bt1D406GiMtL5lW9t7mTFDx1 I2B6kZwlT8y+EScHJgNPhgMZRuClmKR3PNZv34q3eEicFHk27wXq7NkU vB7l6mWl0rthDhRfVJ7JiMz+qg7B7+5y2MBnNw4IBhkVFg== FVT71LMDJ71M5N4BBJG7S42QT4H2K0VS.com. 86400 IN NSEC3 1 1 0 - FVT8070RVMMN14H33TU31073GPDT89UQ NS DS RRSIG FVT71LMDJ71M5N4BBJG7S42QT4H2K0VS.com. 86400 IN RRSIG NSEC3 8 2 86400 20191119061913 20191112050913 12163 com. FcJHBN81vpom4N8ds+1s9KnaL7FrOvI9Fm1Ospv1shMLXnurQoveIba0 mCX+VIsvQZ2eyVYjEvUaW/7LwvL1MniQikcmegHd4Na44KA3SC9ch3pO po4FdQEfkmspQWu/wDY6qFmvoPjTTPxfeUD8V9+L8SpTmRsrin3CxVOJ +zjQKR83QGeeQkCj3AgDOjv+IGWabGPKYX42+HaUrB5o4Q== ;; Received 737 bytes from 192.42.93.30#53(g.gtld-servers.net) in 80 ms cnn.com. 60 IN A 151.101.65.67 cnn.com. 60 IN A 151.101.129.67 cnn.com. 60 IN A 151.101.193.67 cnn.com. 60 IN A 151.101.1.67 cnn.com. 3600 IN NS ns-1086.awsdns-07.org. cnn.com. 3600 IN NS ns-1630.awsdns-11.co.uk. cnn.com. 3600 IN NS ns-47.awsdns-05.com. cnn.com. 3600 IN NS ns-576.awsdns-08.net. ;; Received 236 bytes from 205.251.196.62#53(ns-1086.awsdns-07.org) in 36 ms [2.4.4-RELEASE][admin@sg4860.local.lan]/var/unbound:Keep in mind that once the NS for a domain are found, it is cached and if you need to look up something in that domain that is not already cached, the resolver will talk directly to the authoritative ns for that domain, and doesn't have to walk all the way down from roots again.. Same goes for the NS for the .tld (.com, .net, .edu, etc.) so a trace shows you how the initial resolving of something happens all the way down from roots..
even cnn.com is horrible - 1 minute TTL... JFC!!! people! That is not meant for how dns is suppose to be setup!! I think aws likes such low ttls because they charge for every freaking query ;)
If you want to load balance connections to your different servers serving up something, do it with a loadbalancer, not freaking dns! ;)
-
I am not onsite now. Tomorrow I will do a dig + trace. And post it. I am in southern Mexico.
I see that you saw my freebsd posts with and without forwarding. I will make sure forwarding is disabled when I run the dig +trace. The users will have to tolerate it for a few minutes while I do that.
-
I have done dig plus with the CBC and Google. It is somewhat better now in the morning so I don't know how diagnostic this will be. I will try to add others during the day.
Here is the dig plus
-
I choose the cbc because I knew it was not in the cache. The Google is.
-
Here is a timeout.
-
I have done the necessary research to remind me how DNS works. As dig URL plus does not reveal any helpful information other than a timeout, and because of the way this cycles predictable, I am going to assume that the ISP has some kind of filter in place and use forwarding which only impacts us slightly.
Not all questions can be answered on a forum. Thanks for your help.
-
I have had an issue for the last few days where certain domains, like wikipedia.org, are not able to be looked up successfully by unbound when using DNS Resolver. If I use forwarding to 1.1.1.1, dns lookups are fine. This happens whether or not pfBlockerNG is enabled. Any ideas?
-
@drewsaur said in DNS periodic failure - with pfblocker installed.:
like wikipedia.org, are not able to be looked up successfully by unbound when using DNS Resolver.
That's close to not to be able to find facebook neither.
Be assured : both sites can be resolved.
Knowing that the Internet works well today, it's more your Resolver or the connection between the Resolver and needed root, tld and name servers that isn't working good for you.@drewsaur said in DNS periodic failure - with pfblocker installed.:
Any ideas?
Set the resolver to log 'more details' .... and reading this log to find 'strange' things.
-
I should add - it is all .org domains for the last few days. No other changes in my pfSense configuration. I started another thread: https://forum.netgate.com/topic/148252/sudden-issue-with-org-dns-lookups-using-dns-resolver
-
We have already gone into great detail on how to troubleshoot this and how a resolver works.
if you are having issues resolving all .org domains... Then your isp is having issues talking to one of the NS for that tld
;; QUESTION SECTION: ;org. IN NS ;; ANSWER SECTION: org. 86400 IN NS a0.org.afilias-nst.info. org. 86400 IN NS a2.org.afilias-nst.info. org. 86400 IN NS b0.org.afilias-nst.org. org. 86400 IN NS b2.org.afilias-nst.org. org. 86400 IN NS c0.org.afilias-nst.info. org. 86400 IN NS d0.org.afilias-nst.org.Seems odd that you would have issues talking to all of them? So query them directly for what your looking for.. Does it work?
If your having issues resolve 1 org or a few of them then maybe you have issues just talking to the NS for those domains.
If your having problems with your internet and resolving - then just freaking forward.l Or get another Isp, or bitch them that your connection sucks...
Log your queries.. log your responses.. When you have a problem with domain X, what does your log show?
server: log-queries: yes log-replies: yes -
For us of the original post we are relatively sure that the ISP is playing a part is this. We have rebuilt our systems and in the process were able to observe that the DNS problems did not really appear to be from any pfSense server. What's more we use the same ISP in another location. They have no pfSense server and they still suffer with DNS resolution problems.
Thanks johnpoz.
