Dns not working randomly
-
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: 59still i have other sites/domain that are struggleing loading…
-
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 0tried 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. -
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...
-
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.
-
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 ?
-
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. -
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.
-
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
-
I have the same issue on my mobile phone web view tell me more about the mobile web plz tell me I'm in trouble since last weak.
