Dns not working randomly



  • Hi all,
    short question: i use unbond as resolver.for about 2 days i see that it's not able to resolve several web sites.
    I used before sqid and squidquard setup…which i removed for an easy troubleshooting.
    i don't see much on the dns log...it seems ok...any clue how to troubleshoot this?
    tried process restart, system restart...same issue.
    I also tried using the forwarder...and seems the same =? could not be the dns service the guilty one.
    Any clue?


  • Rebel Alliance Global Moderator

    well what doesn't resolve?  What is the fqdn your trying to resolve?  What do you get from a dns query for it?  ServFail, NX - is the domain dnssec?  Is that broken?

    Really impossible to help you work out the issue without some details, big one is what are you trying to resolve.  Your post seems to suggest more than just 1.  And if I am reading this right your saying it fails to resolve via unbound or forwarder?  You sure the domain in question is just broken?



  • hey,

    not able to resolve stuff like gsmarena.com, or freebsd.com, still facebook and google work file.
    got not error on the browser.may be the browser….safari! it continue to load...without any result.


  • Rebel Alliance Global Moderator

    error in browser?  More than likely its infected and sending you through some proxy.

    Do a simple query to pfsense for what your having issues with, do you get an answer?  On pfsense diag, use the dns lookup.

    What I can tell you for sure is that freebsd.com resolves just fine using unbound..

    ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> freebsd.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24835
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;freebsd.com.                  IN      A

    ;; ANSWER SECTION:
    freebsd.com.            300    IN      A      208.73.211.178
    freebsd.com.            300    IN      A      208.73.210.217
    freebsd.com.            300    IN      A      208.73.210.214
    freebsd.com.            300    IN      A      208.73.210.200

    ;; Query time: 90 msec
    ;; SERVER: 192.168.9.253#53(192.168.9.253)
    ;; WHEN: Tue May 24 11:31:13 CDT 2016
    ;; MSG SIZE  rcvd: 104

    Here are the nameservers unbound would talk to other than roots.

    ;; ANSWER SECTION:
    freebsd.com.            3600    IN      NS      ns2.dsredirection.com.
    freebsd.com.            3600    IN      NS      ns1.dsredirection.com.

    And there is no dnssec setup for freebsd.com which actually kind of surprises me..



  • yeah it works…still not able to resolve gsmarena.com or phonearena.com for example

    dig freebsd.com

    ; <<>> DiG 9.10.3-P4 <<>> freebsd.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47798
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;freebsd.com. IN A

    ;; ANSWER SECTION:
    freebsd.com. 299 IN A 208.73.210.200
    freebsd.com. 299 IN A 208.73.210.217
    freebsd.com. 299 IN A 208.73.210.214
    freebsd.com. 299 IN A 208.73.211.178

    ;; Query time: 808 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Tue May 24 22:37:03 EEST 2016
    ;; MSG SIZE  rcvd: 104


  • Rebel Alliance Global Moderator

    user@ubuntu:~$ dig gsmarena.com

    ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> gsmarena.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34261
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;gsmarena.com.                  IN      A

    ;; ANSWER SECTION:
    gsmarena.com.          3600    IN      A      148.251.77.209

    ;; AUTHORITY SECTION:
    gsmarena.com.          3600    IN      NS      ns.tetracom.com.
    gsmarena.com.          3600    IN      NS      ns1.tetracom-bg.com.
    gsmarena.com.          3600    IN      NS      ns2.tetracom-bg.com.

    ;; Query time: 187 msec
    ;; SERVER: 192.168.9.253#53(192.168.9.253)
    ;; WHEN: Tue May 24 14:50:48 CDT 2016
    ;; MSG SIZE  rcvd

    user@ubuntu:~$ dig phonearena.com

    ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> phonearena.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55258
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;phonearena.com.                        IN      A

    ;; ANSWER SECTION:
    phonearena.com.        7200    IN      A      72.233.105.58

    ;; AUTHORITY SECTION:
    phonearena.com.        86400  IN      NS      ns.salediscovery.com.
    phonearena.com.        86400  IN      NS      ns1.salediscovery.com.

    ;; Query time: 95 msec
    ;; SERVER: 192.168.9.253#53(192.168.9.253)
    ;; WHEN: Tue May 24 14:51:25 CDT 2016
    ;; MSG SIZE  rcvd: 108

    user@ubuntu:~$

    What do you get when you do that query.  Running a resolver can have problems if you have latency issues to where the authoritative servers are, or network connectivity to them.. So what do you get when you do dig for those domains?

    edit:
    "Query time: 808 msec"

    That your query took that long points a latency problem if you ask me..  If your in remote part of the world compared to where the domains are your trying to go.. It might be better and faster for you to just use forwarder and point to either your ISP dns, or a good public in your region of the world, googldns, opendns, etc. etc..



  • will update asap from home



  • ;; Query time: 36 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Wed May 25 21:32:41 EEST 2016
    ;; MSG SIZE  rcvd: 59

    still i have other sites/domain that are struggleing loading…


  • Rebel Alliance Global Moderator

    what site that was that where is was 36ms?

    Yes it is quite possible for some domains to query quite fast while others fail.  As I said before resolver walks down the tree from roots to find the authoritative servers for a specific domain.  Its quite possible that a domains NS are on the other side of the planet from you.  Or on the part of the net that your having issues talking to, etc.



  • this is how a pachet capture looks like:
    23:29:30.083761 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 512
    23:29:30.083780 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 30
    23:29:30.083794 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 375
    23:29:30.083999 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 53
    23:29:30.084713 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:30.084903 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:30.085514 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:30.121822 IP 192.168.100.15.50084 > 17.110.228.160.443: tcp 0
    23:29:30.182759 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 589
    23:29:30.182837 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 746
    23:29:30.183706 IP 192.168.100.15.50088 > 31.13.93.3.443: tcp 780
    23:29:30.183738 IP 192.168.100.15.50088 > 31.13.93.3.443: tcp 215
    23:29:30.184483 IP 192.168.100.15.50086 > 216.58.211.10.443: tcp 601
    23:29:30.184561 IP 192.168.100.15.50086 > 216.58.211.10.443: tcp 311
    23:29:30.210592 IP 31.13.93.3.443 > 192.168.100.15.50088: tcp 0
    23:29:30.210715 IP 31.13.93.3.443 > 192.168.100.15.50088: tcp 45
    23:29:30.211777 IP 192.168.100.15.50088 > 31.13.93.3.443: tcp 0
    23:29:30.215528 IP 216.58.211.10.443 > 192.168.100.15.50086: tcp 0
    23:29:30.215783 IP 216.58.211.10.443 > 192.168.100.15.50086: tcp 0
    23:29:30.225948 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 0
    23:29:30.226175 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 0
    23:29:30.321529 IP 216.58.211.10.443 > 192.168.100.15.50086: tcp 58
    23:29:30.321555 IP 216.58.211.10.443 > 192.168.100.15.50086: tcp 277
    23:29:30.321579 IP 216.58.211.10.443 > 192.168.100.15.50086: tcp 41
    23:29:30.322866 IP 192.168.100.15.50086 > 216.58.211.10.443: tcp 0
    23:29:30.322947 IP 192.168.100.15.50086 > 216.58.211.10.443: tcp 0
    23:29:30.323321 IP 192.168.100.15.50086 > 216.58.211.10.443: tcp 0
    23:29:30.323728 IP 192.168.100.15.50086 > 216.58.211.10.443: tcp 41
    23:29:30.335188 IP 17.110.228.160.443 > 192.168.100.15.50084: tcp 0
    23:29:30.336031 IP 192.168.100.15.50084 > 17.110.228.160.443: tcp 0
    23:29:30.351276 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 512
    23:29:30.351301 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 30
    23:29:30.351321 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 512
    23:29:30.351341 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 121
    23:29:30.353958 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:30.354693 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:30.355415 IP 216.58.211.10.443 > 192.168.100.15.50086: tcp 0
    23:29:30.482297 IP 192.168.100.1.22 > 192.168.100.15.49927: tcp 60
    23:29:30.482631 IP 31.13.93.3.443 > 192.168.100.15.50088: tcp 867
    23:29:30.483367 IP 192.168.100.15.49927 > 192.168.100.1.22: tcp 0
    23:29:30.483458 IP 192.168.100.15.50088 > 31.13.93.3.443: tcp 0
    23:29:30.483798 IP 192.168.100.15.49927 > 192.168.100.1.22: tcp 28
    23:29:30.483834 IP 192.168.100.1.22 > 192.168.100.15.49927: tcp 0
    23:29:30.526837 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 603
    23:29:30.526884 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 241
    23:29:30.570185 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 0
    23:29:30.570411 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 0
    23:29:30.710953 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 512
    23:29:30.710978 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 30
    23:29:30.710998 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 120
    23:29:30.711196 IP 185.63.147.14.443 > 192.168.100.15.50087: tcp 52
    23:29:30.712085 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:30.712108 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:30.712474 IP 192.168.100.15.50087 > 185.63.147.14.443: tcp 0
    23:29:33.381880 IP 192.168.100.15.50070 > 184.30.218.136.80: tcp 0
    23:29:33.450817 IP 184.30.218.136.80 > 192.168.100.15.50070: tcp 0
    23:29:33.451669 IP 192.168.100.15.50070 > 184.30.218.136.80: tcp 0
    23:29:33.481260 IP 192.168.100.15.65314 > 193.231.252.1.53: UDP, length 40
    23:29:33.483163 IP 193.231.252.1.53 > 192.168.100.15.65314: UDP, length 56
    23:29:33.484132 IP 192.168.100.15.50092 > 184.30.218.136.80: tcp 0
    23:29:33.514920 IP 184.30.218.136.80 > 192.168.100.15.50092: tcp 0
    23:29:33.515939 IP 192.168.100.15.50092 > 184.30.218.136.80: tcp 0
    23:29:33.517143 IP 192.168.100.15.50092 > 184.30.218.136.80: tcp 325
    23:29:33.549198 IP 184.30.218.136.80 > 192.168.100.15.50092: tcp 0
    23:29:33.895366 IP 184.30.218.136.80 > 192.168.100.15.50092: tcp 1400
    23:29:34.046857 IP 192.168.100.15.50092 > 184.30.218.136.80: tcp 0
    23:29:34.058359 IP 192.168.100.15.50093 > 184.30.218.136.80: tcp 0
    23:29:34.058706 IP 192.168.100.15.50094 > 184.30.218.136.80: tcp 0
    23:29:34.058730 IP 192.168.100.15.50095 > 184.30.218.136.80: tcp 0
    23:29:34.058966 IP 192.168.100.15.50096 > 184.30.218.136.80: tcp 0
    23:29:34.062505 IP 192.168.100.15.61470 > 193.231.252.1.53: UDP, length 37
    23:29:34.064187 IP 193.231.252.1.53 > 192.168.100.15.61470: UDP, length 87
    23:29:34.065200 IP 192.168.100.15.50097 > 216.58.211.10.80: tcp 0
    23:29:34.086269 IP 184.30.218.136.80 > 192.168.100.15.50096: tcp 0
    23:29:34.086800 IP 184.30.218.136.80 > 192.168.100.15.50095: tcp 0
    23:29:34.087353 IP 192.168.100.15.50096 > 184.30.218.136.80: tcp 0
    23:29:34.087728 IP 192.168.100.15.50095 > 184.30.218.136.80: tcp 0
    23:29:34.088717 IP 192.168.100.15.50096 > 184.30.218.136.80: tcp 396
    23:29:34.088864 IP 184.30.218.136.80 > 192.168.100.15.50094: tcp 0
    23:29:34.089115 IP 192.168.100.15.50095 > 184.30.218.136.80: tcp 460
    23:29:34.089905 IP 192.168.100.15.50094 > 184.30.218.136.80: tcp 0
    23:29:34.090063 IP 184.30.218.136.80 > 192.168.100.15.50093: tcp 0
    23:29:34.090899 IP 192.168.100.15.50093 > 184.30.218.136.80: tcp 0
    23:29:34.091362 IP 192.168.100.15.50094 > 184.30.218.136.80: tcp 471
    23:29:34.091657 IP 192.168.100.15.50093 > 184.30.218.136.80: tcp 459
    23:29:34.095557 IP 216.58.211.10.80 > 192.168.100.15.50097: tcp 0
    23:29:34.096553 IP 192.168.100.15.50097 > 216.58.211.10.80: tcp 0
    23:29:34.097701 IP 192.168.100.15.50097 > 216.58.211.10.80: tcp 339
    23:29:34.116126 IP 184.30.218.136.80 > 192.168.100.15.50096: tcp 0
    23:29:34.117164 IP 184.30.218.136.80 > 192.168.100.15.50095: tcp 0
    23:29:34.117862 IP 184.30.218.136.80 > 192.168.100.15.50096: tcp 1102
    23:29:34.118835 IP 192.168.100.15.50096 > 184.30.218.136.80: tcp 0
    23:29:34.121948 IP 184.30.218.136.80 > 192.168.100.15.50094: tcp 0
    23:29:34.123035 IP 184.30.218.136.80 > 192.168.100.15.50094: tcp 806
    23:29:34.123652 IP 184.30.218.136.80 > 192.168.100.15.50093: tcp 0
    23:29:34.124599 IP 192.168.100.15.50094 > 184.30.218.136.80: tcp 0
    23:29:34.125035 IP 192.168.100.15.50094 > 184.30.218.136.80: tcp 463
    23:29:34.125295 IP 184.30.218.136.80 > 192.168.100.15.50093: tcp 134
    23:29:34.126071 IP 192.168.100.15.50093 > 184.30.218.136.80: tcp 0
    23:29:34.128232 IP 216.58.211.10.80 > 192.168.100.15.50097: tcp 0

    tried to access some other web pages. same result.



  • found the issue….my BAD...with dobble stupid on top.i was checked the block private networks on the wan interface.
    all seems ok now.


  • Rebel Alliance Global Moderator

    What would that have to do with accessing public websites, or doing queries to ns that take 808ms to resolve.  Or domains not resolving at all?

    Yeah that would block rfc1918 creating states through your wan firewalls.  But don't see how that would have anything to do with your issue..



  • have no clue….stlll trying to understand...


  • Rebel Alliance Global Moderator

    Dude blocking rfc1918 to your want wouldn't have anything to do with resolving anything..  Do you have any states with rfc1918 through your wan connection?



  • from pfsesne cli i was able to solve all addresses, problem was it blocked some of them to reach LAN due to this rule.


  • Rebel Alliance Global Moderator

    NO dude it would NOT..  Do you even understand what a rfc1918 is?

    I don't know what your problem was, but blocking rfc1918 to your wan sure wouldn't be it.. What possible public domain could you be looking up or trying to go to on the public internet what would be rfc1918??  Rfc1918 is the private ip space 10.x, 192.168, 172.16 – this addresses are not routable on the oublic internet... So how exactly would that have anything to do with you looking up freebsd.com ?



  • @johnpoz:

    NO dude it would NOT..  Do you even understand what a rfc1918 is?

    I don't know what your problem was, but blocking rfc1918 to your wan sure wouldn't be it.. What possible public domain could you be looking up or trying to go to on the public internet what would be rfc1918??  Rfc1918 is the private ip space 10.x, 192.168, 172.16 – this addresses are not routable on the oublic internet... So how exactly would that have anything to do with you looking up freebsd.com ?

    I perfectly understand what you say….no need to be aggresive.
    Will test again all the same from scratch and try to find out what the problem is.


  • Rebel Alliance Global Moderator

    Not sure were you got aggressiveness out of my clear and precise statements that what you think was the problem could not have anything to do with the problem you were seeing. I for sure did not intend to come off that way.

    Just trying to point out to you, that from the information given there is no way that could have been your problem.

    Rfc1918 inbound to your wan could have nothing to do with anything to do with resolving or accessing public internet sites.  That rule blocks INBOUND traffic to your wan, that is all.  It does not even stop you from talking to rfc1918 outside your wan, as long as YOU created the connection outbound to them, the answer would be allowed.

    If your curious, turn it back on.. Make sure you log it, what do you see in the firewall log for it?  Now what could cause you grief for sure would be if you were blocking that on say a lan interface.  But if that was the case really nothing would of worked at all.  Unless you were not using rfc1918 on your lan side networks.

    Lets get some more information.
    I assume you have a public IP on pfsense wan, ie not rfc1918, your not behind a nat in anyway on your pfsense internet side connection.

    I would also assume your using normal rfc1918 addressing on your lan side networks, network behind pfsense.  And that you nat these connections to your wan IP address.  This is typical out of the box setup for pfsense.

    Your not blocking bogon on lan side are you?  Are you using ipv6?  You could have problems maybe with your ipv6 connectivity, pfsense trying to resolve would attempt to use ipv6 out of the box first.  This could cause problems if something wrong with the ipv6 connectivity either yours or the domains in question NS.

    We also need to validate that your problem is dns based where you can not actually resolve where to go, or that its issue with talking to the actual website via http/https.  Your sniff you posted, where was that taken? I assume your pfsense lan interface.  It really is better to actual see the capture in wireshark, so if you want to post up another one.. Actually post up the pcap file so we can open it in wireshark.  Possible you are having connection issues to some site, where you setting retrans and such..  Its hard to follow the streams in the output you posted to be honest.  That is fine for quick and dirty hey am I seeing traffic from a specific IP, did I get an answer at all, etc.  But to help troubleshoot what the issue might be, it much easier to have the actual cap that can open and view in say wireshark.




  • I just tested….and Yes...you're right!!!
    I did something which I don't remember @ all and broke it...now it works as it should...
    my bad was that i made several changes @ once and forgot the main one who made it work.

    thank you for all details & help.


  • Rebel Alliance Global Moderator

    If I had to make a guess, I would say you changed from resolver to forwarder mode.  If you were having issues resolving stuff from root and talking to all the authoritative ns, or having large amounts of latency in looking the stuff up from them.  Then moving to forwarder mode and asking a local ns for their cached info could for sure clear up any dns based issues.



  • Could be that too…i tried this too