Clients unable to resolve specific site - query response was THROWAWAY
-
Hi all,
since a while my clients can not resolve a specific address: https://xxxxx.stackstorage.com/remote.php/webdav
If I try diagnostics/DNS lookup it can resolve (if I enter xxxxx.stackstorage.com only).
When I connect a client through a hotspot with my mobile the site does resolve.PfBlockerNG is disabled.
Snort is in non-blocking mode.
Version: 2.4.4-RELEASE-p3There a no firewall logs relating to this target IP, and with the local firewall (eset) switched off I still was not able to resolve.
Nslookup on local client: *** pfSense.localdomain can't find xxxx.stackstorage.com: Server failed.I have no idea how to trouble shoot this, and I appreciate any help!
-
I don't get this - now it works. I spent many hours yesterday.
Maybe resolving in Pfsense GUI helped.
Anyway, case closed. -
Maybe they were having an issue... When you get stuff that is not resolving, you need to query the authoritative NS directly to validate - possible failure on dnssec, or mis configured issue on their end, etc.
A good way to test where it might be failing in the resolving process would be to do a +trace..
example
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: dig www.stacktrace.com +trace ; <<>> DiG 9.12.2-P1 <<>> www.stacktrace.com +trace ;; global options: +cmd . 35604 IN NS m.root-servers.net. . 35604 IN NS b.root-servers.net. . 35604 IN NS c.root-servers.net. . 35604 IN NS d.root-servers.net. . 35604 IN NS e.root-servers.net. . 35604 IN NS f.root-servers.net. . 35604 IN NS g.root-servers.net. . 35604 IN NS h.root-servers.net. . 35604 IN NS i.root-servers.net. . 35604 IN NS a.root-servers.net. . 35604 IN NS j.root-servers.net. . 35604 IN NS k.root-servers.net. . 35604 IN NS l.root-servers.net. . 35604 IN RRSIG NS 8 0 518400 20200406170000 20200324160000 33853 . GvT3OCTxgcxBZRtTe1+aEAwsDnV8f/IUrwtCuuYx5vIy9VnNeSq2n+dr zQU9+fbCCMMrTMV34SRPb0LG6xd/SYZgJymoYiwGzN5bXAdMdeUPkfsK S77k+mJOezXwyYig4OprlQRWYbn8GDvCWS6YhwAXEu3N5/NOG2GSSotm ZyKBouka7eGMtcMqOFnnnln0yZv1zYK6JABFPQqWjuOxuIIqtFYf3tpe tBxpvPb3xDgN3lSVL2ZYiAs9DvgfzoTV+MA8ExnoJb5MJcGy6TRiiMj4 c0+zYlX7BWU6VD0JOLjeDGPriSQjRHqfJjufD9P1vb5X1BLfVAuplt/E bVJx9g== ;; 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 b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20200407050000 20200325040000 33853 . tTf893zvluh5P+spvyS9uon7Uzu3HZhYWI+MPBNneVkz7lNWDTRKAYI6 uL07BAgzrAA+X/lUGUfvAk16BSyCMoJy2/2ngMHbdPFdusPkAfMrIDnr YeRUSOj5JxnZGTaHE1lqjOSkQCXeJCUdPbh0LyZF23QQwK6plkx0FLzn KjtCA0SvtSjEAN6GBpi1q0TDDExH59b6F42zXEo9swhIP8LjXFs26LCi g/u1piiS/FdkkWdHVzsw/ZgIndJVi2ExinkORbYG9LCqr+n6QZauBgY0 ZRIbnQFGkfpj6z1hIozZbWfp8SBdxCkB/BnreNTYlR1bW/J2cm+h7v9X GQeHFA== ;; Received 1178 bytes from 199.7.83.42#53(l.root-servers.net) in 42 ms stacktrace.com. 172800 IN NS ns2.mydyndns.org. stacktrace.com. 172800 IN NS ns1.mydyndns.org. stacktrace.com. 172800 IN NS ns3.mydyndns.org. stacktrace.com. 172800 IN NS ns4.mydyndns.org. stacktrace.com. 172800 IN NS ns5.mydyndns.org. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200330044934 20200323033934 56311 com. X8d+VA0H6piJtM33QjsmcHGIAHAf/rrZemEJYtpU5wqfKV5DiwJXkm8e D7FaYcauGloPV1usHu/Yk+jp3Fq07Fa7fOPQcPs8UWp+q6YN3nZOItwS JJxyMw1cAQkpEMXYJMPgCShjHyB1osWgyAjFebRSyIMMRnhBqhKz0tAG OrDnY6Wr6/Ajm+IM7ElE8sL0PJhzQ00JPfSLorvSl8scig== F09NMNL7441439V80D3C9047E0Q4STH6.com. 86400 IN NSEC3 1 1 0 - F09PAQU32I3LL5G0JMDACEBUCPV5KP9E NS DS RRSIG F09NMNL7441439V80D3C9047E0Q4STH6.com. 86400 IN RRSIG NSEC3 8 2 86400 20200401041925 20200325030925 56311 com. Gzv+7ozYm2Y5l7KC3Yrv29dhfCbDlW4JXcH6041OWfUs2ONB034aEoi0 AsokZ5bo4QmEa8R4WMOAj+JaZsrKrIg/O7/5dlM1GnYBKGJpXg2XwG+l xH7BuVWm9lrKoyBZHt3Dxba1P99bnFNrT18S0lQA/77UrU+ebRhYkyq1 tyX1bsNYP4krGz9D1lVUpvW0CVj6K9iKi9ifWBwliVW1eA== ;; Received 698 bytes from 192.5.6.30#53(a.gtld-servers.net) in 31 ms www.stacktrace.com. 3600 IN CNAME stacktrace.com. stacktrace.com. 1 IN A 69.89.18.32 stacktrace.com. 86400 IN NS ns4146.dns.dyn.com. stacktrace.com. 86400 IN NS ns3182.dns.dyn.com. stacktrace.com. 86400 IN NS ns2147.dns.dyn.com. stacktrace.com. 86400 IN NS ns1199.dns.dyn.com. ;; Received 169 bytes from 208.76.61.2#53(ns3.mydyndns.org) in 91 ms [2.4.4-RELEASE][admin@sg4860.local.lan]/root:If you PM me the actual fqdn you were trying to look up, and can see if any current issues with it.
This is pretty much exactly how unbound works, it walks down from roots, finding the authoritative NS for that domain, and then does a direct query to it asking for the record, etc.
-
@jeecee ;
You are forwarding :
to :
and they returned a failed DNSSEC lookup :
(read from bottom to top)also :
which means that your xxxxx.stackstorage.com had a "DNNSEC check not ok".
Using DNSSEC is ok, but keep in mind that sub domains like " xxxxx.stackstorage.com" have a lot of xxxxx parts that come and go. These are the ID's of people that subscribe, or leave services offered by "stackstorage.com".
So there is a lot of DNS-SEC updates happening all the time.If one of the caching (slave) wasn't up to date at the moment of your DNS request, DNSSEC will fail ....
Note that "doing DNSSEC" puts a huge load on DNS servers, traffic is 10 times (?) more, and the most small inconsisty will be fagged as "THROWAWAY" (the rsult) or "SERVFAIL". That's what DNSSEC is all about.
On the other hand, if you do receive a result, an A or AAAA or whatever you were asking for, you have the guarantee that the answer is ok.If it happens again, consider stopping DNSSEC in unbound.
If it still happens, stop the forwarding. Use the resolver - unbound - for what it was designed to do so : let him handle the resolving. Still a no go ? Shut down DNSSEC ( Services > DNS Resolver > Advanced Settings page) -
@Gertjan said in Clients unable to resolve specific site - query response was THROWAWAY:
If it happens again, consider stopping DNSSEC in unbound.
if he is forwarding to dnssec resolver - having dnssec set is just pointless and won't do anything - its going to do dnssec be you ask for it or not... If your forwarding to somewhere that does dnssec, and the dnssec is failing - then yeah your not going to get an answer..
My bad for not reading that closer - I forget that people do stupid shit, like forward when they have a perfectly good resolver right there to use ;) heheeheheh
-
@johnpoz, I saw a similar reply from you elsewhere on this forum regarding dnssec and resolving.
I apparently did not pass the test you suggested when enabling DNSSEC ;).The way I understand it: DNSSEC provides a secured path between client (unbound) and its upstream (root / forwarder). We can debate about its pros and cons, but I choose it.
Then, in DNS server settings, row 1, I have my local box as primary resolver, to keep traffic local if unbound knows it (or what else is the purpose of 127.0.0.1?).
According to https://docs.netgate.com/pfsense/en/latest/dns/unbound-dns-resolver.html I need to enable forwarding mode to even use these DNS settings, hence why I turned it on.
I have 1.1.1.1 listed here as my (choosen, "trusted") upstream DNS servers. Why bypass the whole DNS server chain and burden the root servers?
Maybe much misunderstanding on my part, but if many people misunderstand these settings, maybe the documentation needs to be expanded?
Can you please explain (again) or point to a thread where you most likely, have explained this before? Thanks!"Maybe they were having an issue... When you get stuff that is not resolving": it was resolving ín Pfsense, just not on my clients.
@gertjan: dank je wel for your explanation, that's all new to me.
Reding logfiles is an art, I did not interpret this as "DNNSEC check not ok". The address is indeed my username.
Since I could resolve through my phone's hotspot I assume the pfsense cache was not up to date. Maybe the restart of unbound silently fixed the problem then. -
@jeecee said in Clients unable to resolve specific site - query response was THROWAWAY:
The way I understand it: DNSSEC provides a secured path between client (unbound) and its upstream (root / forwarder).
No that is not what dnssec does... Not even close, maybe your thinking of dnscrypt?
https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
Here is the main take away "DNS data itself is signed by the owner of the data."
Here is a post where I have shown why you don't need to set dnssec if your forwarding.. I have gone over it many times actually..
https://forum.netgate.com/post/867353That whole thread is a discussion on the subject ;)
