DNS periodic failure - with pfblocker installed.



  • I am running the latest community version of pfSense with Suricata, pfBlocker, OpenVPN, High Availability, etc.

    In October after the ISP did an update the whole neighborhood and our office had to reinitialize our modems. There began to be periods where the DNS would work and then it would not. This was predictable, maybe 5 minutes it would work and then maybe 5 minutes it would fail. The users would say it was on and off. This could be observed in DNS diagnositcs. When it was working the latency was very low. When it was failing the latency would be high or the servers would time out.

    I was not on site at the time so I had my tech install an SG2440 which had a very basic install, OpenVPN and Suricata. This I did so that they would have service until I could arrive. My tech is just leaning and I didn't want to overwhelm her.

    On arriving last week I did a scratch install on two machines, one is virtual, and the other is physical. Both had Suricata and pfBlocker and the problems returned.

    When I use the DNS resolver option to go straight to the root DNS we have DNS. I have 3 logs here to share.

    The first is a DNS log with the logging level set to 2.
    DNSLevel2Log.txt

    We don't have IPV6 here so I don't understand those errors.

    The second is from freebsd Unbound is enabled. It is really just a cut and paste.
    freebsdDNSunbound.txt

    There are some interesting things about the second log.
    First is the corruption, the second are the very high latency times.

    The third log is from FreeBSD with pfSense forwarding to the root DNS servers.
    freebsdDNSforwarded.txt

    This is what I used to invoke the second and third log.
    root: unbound-control -c /var/unbound/unbound.conf lookup nbcnews.com


    I have my own ideas on what this might be. Any illuminating comments are welcomed. If the problem is between the chair and the keyboard, please be gentle in your response. I have spent many hours on this, fighting with the cable modem and tweaking pfSense. If it doesn't work it isn't for lack of trying.

    Thanks



  • @reberhar said in DNS periodic failure - with pfblocker installed.:

    Both had Suricata and pfBlocker and the problems returned.

    And with none of these two : no problems ?



  • 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

    unbound.conf.txt


  • LAYER 8 Global Moderator

    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.

    unbound.conf.txt



  • So where in the GUI does I allow me to get rid of the IPV6? Must this always be done in unbound.conf?


  • LAYER 8 Global Moderator

    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.


  • LAYER 8 Global Moderator

    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.


  • LAYER 8 Global Moderator

    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: 244
    

    The 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

    digplus.txt



  • I choose the cbc because I knew it was not in the cache. The Google is.



  • Here is a timeout.

    timeout.txt



  • 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


  • LAYER 8 Global Moderator

    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.



  • @reberhar That appears to be my case as well. The ISPs really seem to be playing DNS games to prepare themselves for the upcoming legislative activities.



  • @reberhar There was an off comment about the traffic shaper in one post. I went through the traffic shaper today and found some odd items, some legacy things and some things that were probably changed as the mouse went by. There were a couple of conflicting items in all this. It now does appear that unbound in functioning well. I will answer back if this turns out not to be the case. I did bump up the DNS priority, but I am unsure if this works when Unbound is not forwarding.



  • @reberhar Yes indeed my DNS is now reliable and fast. My problem with DNS was not the service provider or indeed in the DNS, but an error in the traffic shaper.


Log in to reply