DNS Resolver does not resolve certain hostnames before I restart it
-
@sotirone said in DNS Resolver does not resolve certain hostnames before I restart it:
I recently switched it to use my VPN gateway instead of my WAN and now some hostnames will not resolve until I restart the service.
If you are only allowing for unbound to use your vpn interface - any problem with resolving could be with that connection or they not being able to talk to the authoritative ns for that domain, etc..
Did you flip what you posted between when it can and can not resolve.. the authoritative ns for that domain are
;; ANSWER SECTION: insomnia.gr. 86400 IN NS isaac.ns.cloudflare.com. insomnia.gr. 86400 IN NS rachel.ns.cloudflare.com.
Which are listed in your first paste, the 2nd paste is unbound telling you he it doesn't as yet know the ns for that domain, it would just ask the roots servers to find them..
If you can not talk to the authoritative ns for a specific domain, or find out who they are - then no you would not be able to resolve some specific fqdn in domainxyz.tld
-
@johnpoz I did not flip anything.
I can ping every one of the hostnames of the dns servers so neither me nor my VPN provider is blocking or lacking access to the servers.
It is unusable so I have switched to 9.9.9.9 and forwarding for the time being. What else could be wrong and how could I diagnose?/////////////////
-
@sotirone said in DNS Resolver does not resolve certain hostnames before I restart it:
I can ping every one of the hostnames
You understand ping is not a dns query right ;) Ping what hostname? The roots - well no shit ;)
Can you directly query the ns for the domain in question?
-
@johnpoz Seems like I cannot resolve the ns with unbound:
unbound-control -c /var/unbound/unbound.conf -s rachel.ns.cloudflare.com lookup insomnia.gr [1558340860] unbound-control[400:0] fatal error: could not parse IP: rachel.ns.cloudflare.com
But running nslookup on pfsense itself:
nslookup insomnia.gr rachel.ns.cloudflare.com Server: rachel.ns.cloudflare.com Address: 173.245.58.215#53 Non-authoritative answer: Name: insomnia.gr Address: 104.24.6.31 Name: insomnia.gr Address: 104.24.7.31
-
-s server[@port] IPv4 or IPv6 address of the server to contact. If not given, the address is read from the config file.
That is not the name server to query but the unbound server that unbound-control should try to contact. And it does not resolve. It is asking for an IP address there.
Try:
unbound-control -c /var/unbound/unbound.conf -s 127.0.0.1 lookup insomnia.gr
-
@Derelict said in DNS Resolver does not resolve certain hostnames before I restart it:
unbound-control -c /var/unbound/unbound.conf -s 127.0.0.1 lookup insomnia.gr
that just asks unound who it would ask..
Until actually looked up that will just show the roots.. After actually looked up will show the actual NS for the domain
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: unbound-control -c /var/unbound/unbound.conf -s 127.0.0.1 lookup insomnia.gr The following name servers are used for lookup of insomnia.gr. ;rrset 10789 2 0 2 0 insomnia.gr. 10789 IN NS isaac.ns.cloudflare.com. insomnia.gr. 10789 IN NS rachel.ns.cloudflare.com. ;rrset 86389 1 1 8 0 rachel.ns.cloudflare.com. 86389 IN A 173.245.58.215 rachel.ns.cloudflare.com. 86389 IN RRSIG A 13 4 86400 20190521105148 20190519085148 34505 cloudflare.com. 1eP8k4Fi8txuYv4yv1hnpcI+HWI+KXlOCmZKhtnjM+DV0+x9gI9WO31m2KpREZhPyL+GTz7oIpBMge7UT1DYNg== ;{id = 34505} ;rrset 86389 1 1 8 0 rachel.ns.cloudflare.com. 86389 IN AAAA 2400:cb00:2049:1::adf5:3ad7 rachel.ns.cloudflare.com. 86389 IN RRSIG AAAA 13 4 86400 20190521105148 20190519085148 34505 cloudflare.com. iE2UtNPN777BGLybK9HHgmjB98FnMlE6PNeX0DlEUFZTLDQjOXcj1XzIAZ6gMABBIq95HvzWRji5SiVI8fwM2Q== ;{id = 34505} ;rrset 86389 1 1 8 0 isaac.ns.cloudflare.com. 86389 IN A 173.245.59.177 isaac.ns.cloudflare.com. 86389 IN RRSIG A 13 4 86400 20190521105148 20190519085148 34505 cloudflare.com. zyAH7dWstVBImbh4b/VNaqTT0mrK03ZkYP++WTc7XHHcelY3wOWj3+6m3/GNQLq5Qxg1W8oZnTlOBe8Bvge3Vw== ;{id = 34505} ;rrset 86389 1 1 8 0 isaac.ns.cloudflare.com. 86389 IN AAAA 2400:cb00:2049:1::adf5:3bb1 isaac.ns.cloudflare.com. 86389 IN RRSIG AAAA 13 4 86400 20190521105148 20190519085148 34505 cloudflare.com. +0AsUA5grL3vG5h4ePtO6s1xgt2B2AHBk+vOeGXWVaaXBB69yaU6yxpvyW78p1c84oNc2ZjtDVjE0VudJMpPTQ== ;{id = 34505} Delegation with 2 names, of which 0 can be examined to query further addresses. It provides 4 IP addresses. 2400:cb00:2049:1::adf5:3bb1 not in infra cache. 173.245.59.177 not in infra cache. 2400:cb00:2049:1::adf5:3ad7 rto 376 msec, ttl 889, ping 0 var 94 rtt 376, tA 0, tAAAA 0, tother 0, EDNS 0 assumed. 173.245.58.215 rto 275 msec, ttl 889, ping 7 var 67 rtt 275, tA 0, tAAAA 0, tother 0, EDNS 0 probed. [2.4.4-RELEASE][admin@sg4860.local.lan]/root:
Why don't you do a dig +trace right on pfsense for that - and what do you get back?
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: dig insomnia.gr +trace ; <<>> DiG 9.12.2-P1 <<>> insomnia.gr +trace ;; global options: +cmd . 59280 IN NS a.root-servers.net. . 59280 IN NS b.root-servers.net. . 59280 IN NS c.root-servers.net. . 59280 IN NS d.root-servers.net. . 59280 IN NS e.root-servers.net. . 59280 IN NS f.root-servers.net. . 59280 IN NS g.root-servers.net. . 59280 IN NS h.root-servers.net. . 59280 IN NS i.root-servers.net. . 59280 IN NS j.root-servers.net. . 59280 IN NS k.root-servers.net. . 59280 IN NS l.root-servers.net. . 59280 IN NS m.root-servers.net. . 59280 IN RRSIG NS 8 0 518400 20190601170000 20190519160000 25266 . Pd94nNBB/dmXuuWIe7TLs13ewpPca2Tg8kioylE0spqDktx8NYJ+3DM8 6d5aB0ae9b3lF1jD9+paiOpiXwFvHTV/xr13ziNps2viACRAUF8dqovu 694nbsXgMjSyeAbG+qOMj5dfuC3XUFYtRo/ZATU0eTktD3m7AhQjPEpi 7nkJvx+SDsrus4jwocMOmh7xKWGZ6dbop9gtM169ZrI11GK3b17q/uvP +EQKMyYUkGvG6X705P+JjxPfmviBnMMnUDIKxa6EV4CawBfUw6DE8MNp K6qXdzSq0wqOyscyvRByFatcgZqmfVelH7Gs645J/CIETQiAF0QxGfJD xfTQzw== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms gr. 172800 IN NS gr-d.ics.forth.gr. gr. 172800 IN NS grdns.ics.forth.gr. gr. 172800 IN NS gr-c.ics.forth.gr. gr. 172800 IN NS gr-at.ics.forth.gr. gr. 172800 IN NS gr-m.ics.forth.gr. gr. 172800 IN NS estia.ics.forth.gr. gr. 86400 IN DS 35136 7 2 F7BF4C362B838C2069C9083FD38846BBB5D79EDBDE298F9268997307 EA7DD5C3 gr. 86400 IN RRSIG DS 8 1 86400 20190602050000 20190520040000 25266 . J3bAJa/8lmeIe4cS4M0zNmMsEz1vQ9xhi1jASAWZqZ/++9vRG+K/7MQ2 KfEX92IGRGqe0IrDqhcGxjjKFwIOnCXpFNA3k02fuLV/sOPa3xicEycM 8J3lsibtk/wJn3cY6c8nTX1jNqzobofzl87gzl08D126nwJtO2aP5D/r wuEk0hoHEFQGOjiLCvEd56aF/aPUGcIWSvNV8Hw1Oq/TSbWqkk6DAxfD 6QhR+9/0leOLn7IGt+ZWidH8vyPHflOb3KYETHW3H+yI20v/S09i5mFe rTlzxX/pD8h38fGs40FnYDbg5OCqR66CNaW59kVPtBnt7qmxS/XE7tTj qOPlzg== ;; Received 738 bytes from 199.9.14.201#53(b.root-servers.net) in 79 ms insomnia.gr. 10800 IN NS isaac.ns.cloudflare.com. insomnia.gr. 10800 IN NS rachel.ns.cloudflare.com. e5housd976jc4sbdh69jcejib7h0fh77.gr. 1800 IN NSEC3 1 1 10 BEEF E5N5DKOK964HISOPIF2UDK9VCTDDSQS9 NS SOA RRSIG DNSKEY NSEC3PARAM e5housd976jc4sbdh69jcejib7h0fh77.gr. 1800 IN RRSIG NSEC3 7 2 1800 20190619060140 20190520060140 7835 gr. pyWAmbpslWBD8+c4PaMj4+rB7W/wWJbL9NJwRqbYmh/CFhx4Mfntqopn wLZlWYWVWq08tj/4o0Lo9Fj3I8/ORhKy8XhRjfucJLOtCHqLNr45FiqD YqRpobyRL9oYntY6TiF5Yi0dqEHhd3ZloE7SBJAxw71kr2TAklfHDRBH Yqs= pqitkejamofi80bksbq392v5so3anba5.gr. 1800 IN NSEC3 1 1 10 BEEF PQQFK94F84UPU0SMUK1FNB2P8NUFNCFC DNAME RRSIG pqitkejamofi80bksbq392v5so3anba5.gr. 1800 IN RRSIG NSEC3 7 2 1800 20190619060140 20190520060140 7835 gr. UfgOiI+YZFYVlgCMEuUAeL5j8i6WBJzUf8Gaq+Syai6EBWJ13rPNcxfC geBZTxj9dYonhjh1wMc9134S9ny7QhtNQlUvGU5rQGrQly3DjiahgDnP 38ma8OzgX5A5J4m5o1AUQqE+JFuIi39dj6NceWqi4chz/WFdLcDCS0bs VzA= ;; Received 606 bytes from 194.0.1.25#53(gr-c.ics.forth.gr) in 77 ms insomnia.gr. 300 IN A 104.24.6.31 insomnia.gr. 300 IN A 104.24.7.31 ;; Received 72 bytes from 173.245.59.177#53(isaac.ns.cloudflare.com) in 30 ms [2.4.4-RELEASE][admin@sg4860.local.lan]/root:
Please notice the 300 second ttl - so like every 5 minutes unbound would have to go ask those NS again.. Which if your having network issues talking to them - yeah could pose a problem..
-
@johnpoz dig +trace fails with:
BAD (HORIZONTAL) REFERRAL
dig: too many lookups -
How about you post the actual output?
-
Yeah lets see where your getting that, since I am not seeing that at all..
Post up your dig +trace like I did.
Other than odd serial number, and out of norm ttl that domain checks out fine..
The trace is pretty straight forward, roots tell you ns for .gr, those tell you ns for domain, it replies the answer don't see where you would get bad referral.. Maybe your isp is dicking with your queries? I do not see any delegation or cnames even follow.
-
@Derelict I am trying to post the output but it is too long for the forum. Here is a part of it, it then just repeats.
dig insomnia.gr +trace ; <<>> DiG 9.12.2-P1 <<>> insomnia.gr +trace ;; global options: +cmd . 39469 IN NS h.root-servers.net. . 39469 IN NS f.root-servers.net. . 39469 IN NS a.root-servers.net. . 39469 IN NS d.root-servers.net. . 39469 IN NS e.root-servers.net. . 39469 IN NS k.root-servers.net. . 39469 IN NS l.root-servers.net. . 39469 IN NS i.root-servers.net. . 39469 IN NS b.root-servers.net. . 39469 IN NS g.root-servers.net. . 39469 IN NS c.root-servers.net. . 39469 IN NS j.root-servers.net. . 39469 IN NS m.root-servers.net. . 39469 IN RRSIG NS 8 0 518400 20190602170000 20190520160000 25266 . PLUnP901+Bk4vpIcVv0AHignWrbwzWwl88ln3SvytL/h7NUuIxJ6Fb3e UIsxyIFcm/fnNN57HkBhcR/VGCkwFhA3YYnhE1iekkXee8gMOPwBgtz0 iEMNqo47PaJoLFXbNNhXIr/OARj9YDbR6qfzc5Nc9RGPWaNXgku1VtUV 9tSReaeae7UsSAChYCZ4dfbWJ1UQ2QdJeJi9dPa9Z/rSS2c0O31wuwXR dNTlCFxdwZUlu7tvHWAN2GcNrlmkbPeDRrvSpOYJq+hIXNydtYde2UBi g3x4IVeN/lKKDeov3te3NhL+cSCOJCPebVRujEctBNHwHZBP89F/qJUO ASuv1g== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 231 ms gr. 85374 IN NS grdns.ics.forth.gr. gr. 85374 IN NS gr-at.ics.forth.gr. gr. 85374 IN NS gr-m.ics.forth.gr. gr. 85374 IN NS gr-c.ics.forth.gr. gr. 85374 IN NS estia.ics.forth.gr. gr. 85374 IN NS gr-d.ics.forth.gr. gr. 13472 IN DS 35136 7 2 F7BF4C362B838C2069C9083FD38846BBB5D79EDBDE298F9268997307 EA7DD5C3 gr. 13472 IN RRSIG DS 8 1 86400 20190601170000 20190519160000 25266 . KFoU4cRGsr3YdCffHY5vjUQVTq0Hh7aH/3GgkfB7cF9QPd9r+jfJVlDP EK34JNNzZVxB1VxZDDa+B62uh0Xt3nK15WBODSO+i6UR+HzVo5yK39Xh Ltp+mRAJRfdSbXGxsWgzs28PnrzN1VZUmXvF/6B+nfaRAbhAz7ppi/M0 eE18qUKi20KRuTzFPlgpq/chb7MCG3A1NsZW04rmdvkqYZ/z7qSrlMgX zz/bF4XyJ6llXHB0G9WVa1+ruTB7nDoWdis10Pqhsjk6LIh/LRgGgmLe vkpG4QKrRvyanWiWwVHUfjFew2EjMMclxP5D8aEK7dVVRNaKHOdtcHpG VPyRTw== ;; Received 530 bytes from 192.36.148.17#53(i.root-servers.net) in 41 ms gr. 85365 IN NS gr-m.ics.forth.gr. gr. 85365 IN NS grdns.ics.forth.gr. gr. 85365 IN NS gr-c.ics.forth.gr. gr. 85365 IN NS estia.ics.forth.gr. gr. 85365 IN NS gr-at.ics.forth.gr. gr. 85365 IN NS gr-d.ics.forth.gr. gr. 13463 IN DS 35136 7 2 F7BF4C362B838C2069C9083FD38846BBB5D79EDBDE298F9268997307 EA7DD5C3 gr. 13463 IN RRSIG DS 8 1 86400 20190601170000 20190519160000 25266 . KFoU4cRGsr3YdCffHY5vjUQVTq0Hh7aH/3GgkfB7cF9QPd9r+jfJVlDP EK34JNNzZVxB1VxZDDa+B62uh0Xt3nK15WBODSO+i6UR+HzVo5yK39Xh Ltp+mRAJRfdSbXGxsWgzs28PnrzN1VZUmXvF/6B+nfaRAbhAz7ppi/M0 eE18qUKi20KRuTzFPlgpq/chb7MCG3A1NsZW04rmdvkqYZ/z7qSrlMgX zz/bF4XyJ6llXHB0G9WVa1+ruTB7nDoWdis10Pqhsjk6LIh/LRgGgmLe vkpG4QKrRvyanWiWwVHUfjFew2EjMMclxP5D8aEK7dVVRNaKHOdtcHpG VPyRTw== ;; BAD (HORIZONTAL) REFERRAL ;; Received 530 bytes from 139.91.191.3#53(estia.ics.forth.gr) in 41 ms gr. 85365 IN NS gr-d.ics.forth.gr. gr. 85365 IN NS estia.ics.forth.gr. gr. 85365 IN NS grdns.ics.forth.gr. gr. 85365 IN NS gr-at.ics.forth.gr. gr. 85365 IN NS gr-m.ics.forth.gr. gr. 85365 IN NS gr-c.ics.forth.gr. gr. 13463 IN DS 35136 7 2 F7BF4C362B838C2069C9083FD38846BBB5D79EDBDE298F9268997307 EA7DD5C3 gr. 13463 IN RRSIG DS 8 1 86400 20190601170000 20190519160000 25266 . KFoU4cRGsr3YdCffHY5vjUQVTq0Hh7aH/3GgkfB7cF9QPd9r+jfJVlDP EK34JNNzZVxB1VxZDDa+B62uh0Xt3nK15WBODSO+i6UR+HzVo5yK39Xh Ltp+mRAJRfdSbXGxsWgzs28PnrzN1VZUmXvF/6B+nfaRAbhAz7ppi/M0 eE18qUKi20KRuTzFPlgpq/chb7MCG3A1NsZW04rmdvkqYZ/z7qSrlMgX zz/bF4XyJ6llXHB0G9WVa1+ruTB7nDoWdis10Pqhsjk6LIh/LRgGgmLe vkpG4QKrRvyanWiWwVHUfjFew2EjMMclxP5D8aEK7dVVRNaKHOdtcHpG VPyRTw== ;; BAD (HORIZONTAL) REFERRAL ;; Received 530 bytes from 194.0.11.102#53(gr-d.ics.forth.gr) in 41 ms gr. 85365 IN NS gr-at.ics.forth.gr. gr. 85365 IN NS gr-d.ics.forth.gr. gr. 85365 IN NS gr-c.ics.forth.gr. gr. 85365 IN NS gr-m.ics.forth.gr. gr. 85365 IN NS grdns.ics.forth.gr. gr. 85365 IN NS estia.ics.forth.gr. gr. 13463 IN DS 35136 7 2 F7BF4C362B838C2069C9083FD38846BBB5D79EDBDE298F9268997307 EA7DD5C3 gr. 13463 IN RRSIG DS 8 1 86400 20190601170000 20190519160000 25266 . KFoU4cRGsr3YdCffHY5vjUQVTq0Hh7aH/3GgkfB7cF9QPd9r+jfJVlDP EK34JNNzZVxB1VxZDDa+B62uh0Xt3nK15WBODSO+i6UR+HzVo5yK39Xh Ltp+mRAJRfdSbXGxsWgzs28PnrzN1VZUmXvF/6B+nfaRAbhAz7ppi/M0 eE18qUKi20KRuTzFPlgpq/chb7MCG3A1NsZW04rmdvkqYZ/z7qSrlMgX zz/bF4XyJ6llXHB0G9WVa1+ruTB7nDoWdis10Pqhsjk6LIh/LRgGgmLe vkpG4QKrRvyanWiWwVHUfjFew2EjMMclxP5D8aEK7dVVRNaKHOdtcHpG VPyRTw== ;; BAD (HORIZONTAL) REFERRAL ;; Received 530 bytes from 78.104.145.227#53(gr-at.ics.forth.gr) in 40 ms gr. 85365 IN NS gr-at.ics.forth.gr. gr. 85365 IN NS gr-c.ics.forth.gr. gr. 85365 IN NS gr-m.ics.forth.gr. gr. 85365 IN NS estia.ics.forth.gr. gr. 85365 IN NS grdns.ics.forth.gr. gr. 85365 IN NS gr-d.ics.forth.gr. gr. 13463 IN DS 35136 7 2 F7BF4C362B838C2069C9083FD38846BBB5D79EDBDE298F9268997307 EA7DD5C3 gr. 13463 IN RRSIG DS 8 1 86400 20190601170000 20190519160000 25266 . KFoU4cRGsr3YdCffHY5vjUQVTq0Hh7aH/3GgkfB7cF9QPd9r+jfJVlDP EK34JNNzZVxB1VxZDDa+B62uh0Xt3nK15WBODSO+i6UR+HzVo5yK39Xh Ltp+mRAJRfdSbXGxsWgzs28PnrzN1VZUmXvF/6B+nfaRAbhAz7ppi/M0 eE18qUKi20KRuTzFPlgpq/chb7MCG3A1NsZW04rmdvkqYZ/z7qSrlMgX zz/bF4XyJ6llXHB0G9WVa1+ruTB7nDoWdis10Pqhsjk6LIh/LRgGgmLe vkpG4QKrRvyanWiWwVHUfjFew2EjMMclxP5D8aEK7dVVRNaKHOdtcHpG VPyRTw== ;; BAD (HORIZONTAL) REFERRAL ;; Received 530 bytes from 78.104.145.227#53(gr-at.ics.forth.gr) in 40 ms
-
Well yeah you got something going on there..
Your TTLs are all wrong...
Your gr ttls are 85374, if you would of actually gotten them from the roots they would 172800
Those are NOT correct.. its like something is intercepting your queries..
Simple enough to ask a root server for the NS of gr.. Pick one of the roots and ask them for them..
$ dig @e.root-servers.net gr. NS ; <<>> DiG 9.14.1 <<>> @e.root-servers.net gr. NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13538 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 11 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;gr. IN NS ;; AUTHORITY SECTION: gr. 172800 IN NS gr-c.ics.forth.gr. gr. 172800 IN NS gr-d.ics.forth.gr. gr. 172800 IN NS gr-m.ics.forth.gr. gr. 172800 IN NS estia.ics.forth.gr. gr. 172800 IN NS gr-at.ics.forth.gr. gr. 172800 IN NS grdns.ics.forth.gr. ;; ADDITIONAL SECTION: gr-c.ics.forth.gr. 172800 IN A 194.0.1.25 gr-d.ics.forth.gr. 172800 IN A 194.0.11.102 gr-m.ics.forth.gr. 172800 IN A 194.0.4.10 estia.ics.forth.gr. 172800 IN A 139.91.191.3 gr-at.ics.forth.gr. 172800 IN A 78.104.145.227 grdns.ics.forth.gr. 172800 IN A 139.91.1.1 gr-c.ics.forth.gr. 172800 IN AAAA 2001:678:4::19 gr-d.ics.forth.gr. 172800 IN AAAA 2001:678:e:102::53 gr-m.ics.forth.gr. 172800 IN AAAA 2001:678:7::4:10 estia.ics.forth.gr. 172800 IN AAAA 2001:648:2c30::191:3 ;; Query time: 11 msec ;; SERVER: 192.203.230.10#53(192.203.230.10) ;; WHEN: Mon May 20 20:13:27 Central Daylight Time 2019 ;; MSG SIZE rcvd: 366
That you didn't get back the FULL ttl something is not right... You should always get back the FULL ttl for the NS from roots.. when you ask them or trace..
Do a sniff on your wan when you do your trace so you can see exactly what is being asked, and what comes back.. But not getting back full TTL from roots points to possible interception..
When you ask an authoritative ns for a record that its authoritative for you will always get back the FULL TTL, not something less..
OR?? your not actually asking them for the domain in question but ns for gr again?? Do you have query name minimization set???
Nope I just tested that - and then doesn't doesn't cause the problem your seeing.. And getting back full TTL in every trace still, etc.. There is something going on - that your not getting back full TTL screams not actually talking to the authoritative NS..
edit: Just noticed this as well.. Why would it take you 231ms to retrieve the roots from local???
;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 231 ms
That should almost always be like 0 or 1 ms.. Did you not run that command that dig +trace command on pfsense itself? Or your running forwarder? on the local machine you ran it on?
-
same issue after update to 2.4.4-RELEASE-p3
i can t resolve vertele.eldiario.es, but if restart pfsense it works a few moments after fall down again
no ping
ping vertele.eldiario.es
PING cec01.usg.edgetcdn.com (74.208.86.233) 56(84) bytes of data.
--- cec01.usg.edgetcdn.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 159ms -
@diego_81 said in DNS Resolver does not resolve certain hostnames before I restart it:
same issue after update to 2.4.4-RELEASE-p3
i can t resolve vertele.eldiario.es, but if restart pfsense it works a few moments after fall down again
no ping
ping vertele.eldiario.es
PING cec01.usg.edgetcdn.com (74.208.86.233) 56(84) bytes of data.
--- cec01.usg.edgetcdn.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 159msThat says it is RESOLVING fine. ICMP isn't being returned. You might want to stop looking at DNS resolution and start looking at why you cannot ping 74.208.83.233 at that moment in time.
-
@Derelict i love you!!!!!
snort was blocking http traffic to this websitesthnks!!!!!!
-
Amazing.