DNS Servers being blocked
-
So, I've started looking into and implementing on what's being discussed here and I've learned that if you run on DNSSEC and used OpenDNS as the forwarder for the Resolver that it fails. OpenDNS doesn't use DNSSEC. It apparently uses DNSCrypt. It looks like the benefit is that traffic is encrypted but how would that be any stronger than using DNSSEC with selecting to use SSL/TLS over port 853?
I'm also struggling with what is being recommended here. Are you saying that rather than using external DNS servers in the DHCP options I should use a local Resolver like pfSense? Simple enough. But that resolver needs to have forwarders to know what data to cache, correct. Which servers are you saying to use if not someone like OpenDNS, QuadDNS, or Google? That wouldn't preclude the use of Forwarders, only limit the amount of traffic to them to once per TTL, no?
@NogBadTheBad
I run Suricata blocking on the WAN and logging on the LAN. That way if something blocks and is triggered on the WAN, I can see the corresponding LAN entry that may have generated the bad request. Very useful if it's an infection or something like that.@johnpoz
That .top rule is 2023883. Rule is:
alert dns $HOME_NET any -> any any (msg:"ET DNS Query to a *.top domain - Likely Hostile"; dns_query; content:".top"; nocase; isdataat:!1,relative; threshold:type limit, track by_src, count 1, seconds 30; reference:url,www.symantec.com/connect/blogs/shady-tld-research-gdn-and-our-2016-wrap; reference:url,www.spamhaus.org/statistics/tlds/; classtype:bad-unknown; sid:2023883; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2017_02_07, updated_at 2017_02_07;) -
@stewart said in DNS Servers being blocked:
But that resolver needs to have forwarders to know what data to cache, correct.
NO... Unbound out of the box on pfsense is RESOLVER... You should prob look up the difference between a resolver and a forwarder as first thing in your journey to understanding DNS ;)
BTW.. Per the rfc on answering stale.. it will give a TTL of 1 for stale records if they have not been resolved by time the client is given an answer..
" If so, it adds that data to the response message and SHOULD set the TTL of each expired record in the message to 1 second"
https://tools.ietf.org/id/draft-tale-dnsop-serve-stale-01.html -
@stewart said in DNS Servers being blocked:
So, I've started looking into and implementing on what's being discussed here and I've learned that if you run on DNSSEC and used OpenDNS as the forwarder for the Resolver that it fails. OpenDNS doesn't use DNSSEC. It apparently uses DNSCrypt. It looks like the benefit is that traffic is encrypted but how would that be any stronger than using DNSSEC with selecting to use SSL/TLS over port 853?
Without getting too far into the weeds: don't look at DNSSEC like it's a "different" critter. It's still the same protocol, with some additional lookups and the "crypto" is simply public key methods to determine authenticity - not 'encrypt' traffic. It still uses port 53. Hence the reason that DNSSEC doesn't change anything about your existing DNS and flows, per se. Other incantations, like DoH (DNS over HTTPS) is meant to encrypt the traffic and it can easily bypass controls - by intention. Also means that CNC could then bypass protections.
You cannot perform DNSSEC validation and forward - that will, fail. DNSSEC validation is (as previously mentioned), the validation of authenticity of namespace and validation of authenticity of infrastructure. It does not 'encrypt' the traffic.
I'm also struggling with what is being recommended here. Are you saying that rather than using external DNS servers in the DHCP options I should use a local Resolver like pfSense? Simple enough. But that resolver needs to have forwarders to know what data to cache, correct. Which servers are you saying to use if not someone like OpenDNS, QuadDNS, or Google? That wouldn't preclude the use of Forwarders, only limit the amount of traffic to them to once per TTL, no?
External resolvers (outside your control) should always be a last resort option. Internal (organizational control/policy) DNS servers are always the preference. You want a lookup to appear as:
internal consumer => internal DNS servers => Internet Root => <follow NS chain until resolution>
Caching is driven by TTL (on the response). Thus, a recursive DNS Server doesn't "forward". It starts with the Root DNS Servers (".") and then follows the namespace of the query until resolution. Each 'hop' will be cached for the duration of TTL.
Eg: "Query 1" = www.google.com@NogBadTheBad
I run Suricata blocking on the WAN and logging on the LAN. That way if something blocks and is triggered on the WAN, I can see the corresponding LAN entry that may have generated the bad request. Very useful if it's an infection or something like that.@johnpoz
That .top rule is 2023883. Rule is:
alert dns $HOME_NET any -> any any (msg:"ET DNS Query to a *.top domain - Likely Hostile"; dns_query; content:".top"; nocase; isdataat:!1,relative; threshold:type limit, track by_src, count 1, seconds 30; reference:url,www.symantec.com/connect/blogs/shady-tld-research-gdn-and-our-2016-wrap; reference:url,www.spamhaus.org/statistics/tlds/; classtype:bad-unknown; sid:2023883; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2017_02_07, updated_at 2017_02_07;) -
@justme2 said in DNS Servers being blocked:
@stewart said in DNS Servers being blocked:
So, I've started looking into and implementing on what's being discussed here and I've learned that if you run on DNSSEC and used OpenDNS as the forwarder for the Resolver that it fails. OpenDNS doesn't use DNSSEC. It apparently uses DNSCrypt. It looks like the benefit is that traffic is encrypted but how would that be any stronger than using DNSSEC with selecting to use SSL/TLS over port 853?
Without getting too far into the weeds: don't look at DNSSEC like it's a "different" critter. It's still the same protocol, with some additional lookups and the "crypto" is simply public key methods to determine authenticity - not 'encrypt' traffic. It still uses port 53. Hence the reason that DNSSEC doesn't change anything about your existing DNS and flows, per se. Other incantations, like DoH (DNS over HTTPS) is meant to encrypt the traffic and it can easily bypass controls - by intention. Also means that CNC could then bypass protections.
You cannot perform DNSSEC validation and forward - that will, fail. DNSSEC validation is (as previously mentioned), the validation of authenticity of namespace and validation of authenticity of infrastructure. It does not 'encrypt' the traffic.
I'm also struggling with what is being recommended here. Are you saying that rather than using external DNS servers in the DHCP options I should use a local Resolver like pfSense? Simple enough. But that resolver needs to have forwarders to know what data to cache, correct. Which servers are you saying to use if not someone like OpenDNS, QuadDNS, or Google? That wouldn't preclude the use of Forwarders, only limit the amount of traffic to them to once per TTL, no?
External resolvers (outside your control) should always be a last resort option. Internal (organizational control/policy) DNS servers are always the preference. You want a lookup to appear as:
internal consumer => internal DNS servers => Internet Root => <follow NS chain until resolution>
Caching is driven by TTL (on the response). Thus, a recursive DNS Server doesn't "forward". It starts with the Root DNS Servers (".") and then follows the namespace of the query until resolution. Each 'hop' will be cached for the duration of TTL.
Eg: "Query 1" = www.google.com<hit submit by mistake at this point>
Once you've hit the roots and lookup of the com servers - you'll cache that for the duration of TTL. Any successive queries within the TLD of COM don't need to re-validate. You can go direct to the com servers.
@NogBadTheBad
I run Suricata blocking on the WAN and logging on the LAN. That way if something blocks and is triggered on the WAN, I can see the corresponding LAN entry that may have generated the bad request. Very useful if it's an infection or something like that.@johnpoz
That .top rule is 2023883. Rule is:
alert dns $HOME_NET any -> any any (msg:"ET DNS Query to a *.top domain - Likely Hostile"; dns_query; content:".top"; nocase; isdataat:!1,relative; threshold:type limit, track by_src, count 1, seconds 30; reference:url,www.symantec.com/connect/blogs/shady-tld-research-gdn-and-our-2016-wrap; reference:url,www.spamhaus.org/statistics/tlds/; classtype:bad-unknown; sid:2023883; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, created_at 2017_02_07, updated_at 2017_02_07;)That's indicative of a mistake IF it's a recursive DNS server. If it's not a recursive DNS Server (eg: by policy) - then the rule is correct. Likely the $DNS_SERVERS (sp?) variable?
-
@johnpoz said in DNS Servers being blocked:
@stewart said in DNS Servers being blocked:
But that resolver needs to have forwarders to know what data to cache, correct.
NO... Unbound out of the box on pfsense is RESOLVER... You should prob look up the difference between a resolver and a forwarder as first thing in your journey to understanding DNS ;)
As johnpoz points out, there is a distinct difference between "resolver" and "forwarder". A forwarder means that you need an answer and are -forwarding- it to another party, asking them to do all the work to get you the answer. A -resolver- does all the work to obtain the answer and doesn't rely on a specific 3rd party to obtain the answer. A forwarder in common terms, means that 3rd party (to whom your forward all your queries), now has a record of everything you asked for. Think of it from a logging stance. With the roots and TLD servers, they only see the "lower level(s)". A forwarder sees the entire FQDN requested - of every request.
BTW.. Per the rfc on answering stale.. it will give a TTL of 1 for stale records if they have not been resolved by time the client is given an answer..
" If so, it adds that data to the response message and SHOULD set the TTL of each expired record in the message to 1 second"
https://tools.ietf.org/id/draft-tale-dnsop-serve-stale-01.htmlOnly issue is that it's a draft and not an RFC, eg: no obligation to accept or follow. On the plus, someone took the time to document what -they- believe would be most optimal behavior. Although apparently this draft has dependency on Vixie's resimprove (evidently also in draft state).
-
I thought understood the difference between a resolver and a forwarder but resolvers need to forward on the request somewhere if it doesn't have the answer, right? So I would assume that resolvers are also forwarders in that regard but maybe that's just the wrong terminology. If a resolver doesn't have an answer, where does it look? Automatically to the root servers? If so then I've been wrong in assuming you need to provide upstream servers for them to check. When set to resolver I've always told it to use forwarders and DNSSEC. You can use OpenDNS as the forwarder but if you switch on DNSSEC it fails so using DNSSEC and forwarding appear to at least do something. If I do switch on forwarders in the resolver, does that essentially just turn it into a forwarder with a local copy of the records inside of the TTL window? It still forwards the requests on but only once per record as long as it's in the TTL?
Would the proper setup, then, be turning off forwarders and enabling DNSSEC? Is there anyway to integrate the features of something like OpenDNS and QuadDNS in that mode? Being able to stop DNS resolutions for malicious or restricted domains is helpful.
-
@stewart said in DNS Servers being blocked:
I thought understood the difference between a resolver and a forwarder but resolvers need to forward on the request somewhere if it doesn't have the answer, right? So I would assume that resolvers are also forwarders in that regard but maybe that's just the wrong terminology. If a resolver doesn't have an answer, where does it look? Automatically to the root servers? If so then I've been wrong in assuming you need to provide upstream servers for them to check. When set to resolver I've always told it to use forwarders and DNSSEC. You can use OpenDNS as the forwarder but if you switch on DNSSEC it fails so using DNSSEC and forwarding appear to at least do something. If I do switch on forwarders in the resolver, does that essentially just turn it into a forwarder with a local copy of the records inside of the TTL window? It still forwards the requests on but only once per record as long as it's in the TTL?
A resolver doesn't "forward" to obtain answer. If a resolver doesn't have the answer ("in cache"), it will start with the internet Root Servers to obtain the answer. Once the authoritative nameserver(s) is determined, it is queried for the value requested and then response provided back to the consumer.
A forwarder, simply does: 1) If requested value is already in cache, provide answer from cache or 2) ask configured forwarder(s) to obtain answer on your behalf.
The behavior of most DNS Servers is that when they are forwarding - they will cache the results for the TTL duration received. Yes, they re-use the answer provided that the record has not reached TTL duration.
Would the proper setup, then, be turning off forwarders and enabling DNSSEC? Is there anyway to integrate the features of something like OpenDNS and QuadDNS in that mode? Being able to stop DNS resolutions for malicious or restricted domains is helpful.
Optimal is to turn off forwarders, enabling DNSSEC validation and add RPZ feed(s) as appropriate. Unfortunately, you can either forward or obtain the benefit of DNSSEC validation (requires resolver, not forwarder), as you cannot validate unless you are performing the resolution. DNS reputational Feeds are the means to protect against domains in the fashion to which you are referring.
-
OK. I get it now. So, besides enabling DNSBL in pfBlockerNG and setting the unit to be a resolver with DNSSEC on and forwarding off, is there anything else I should do? I see there is an Alexa whitelist to enable. I see that the EasyList is enabled but no feeds are in there. One guide I've found is here if I want to upgrade to the dev version or here if I want to use the general release. If those look right then I'll read up on them and figure out how to get my own feeds integrated in and stop relying on third party servers entirely.
-
@justme2 said in DNS Servers being blocked:
With the roots and TLD servers, they only see the "lower level(s)". A forwarder sees the entire FQDN requested - of every request.
Not actually true, unless you turn on Qname Minimization.. And for sure using strict is going to break a lot of domains.. MS has many of them that are broken with this is on... Tested that even before they added it to the gui to be able to enable.
But completely agree with you in a perfect world.. roots would only see queries for the tld NS, the tld ns for that domain would only see queries for the domain.tld, and then the authoritative ns for the domain would see the fqdn query host.domain.tld
In theory this seems ideal is what everyone would want, but in practice doesn't always work out that well.
Pfsense unbound config is pretty good out of the box.. I change it to not listen on all, and only the interfaces I want and only query outbound on interface(s) I need. Also change from transparent mode to static type. I also turn off the automatic ACLs and do my own.
But the config out of the box should really work for pretty much everyone.
Oh set to only register static dhcp as well.. And enable prefetch and serve 0 ttl option.
-
@johnpoz said in DNS Servers being blocked:
@justme2 said in DNS Servers being blocked:
With the roots and TLD servers, they only see the "lower level(s)". A forwarder sees the entire FQDN requested - of every request.
RE: minimization, correct. Should have more clearly (or perhaps more generically correctly) stated that the roots and TLD infrastructure may see the full FQDN, but no other 3rd party would have full visibility of all the queries generated by an organization. Generally, roots/TLD infrastructure are uninterested parties due to mandatory involvement.
Pfsense unbound config is pretty good out of the box.. I change it to not listen on all, and only the interfaces I want and only query outbound on interface(s) I need. Also change from transparent mode to static type. I also turn off the automatic ACLs and do my own.
Yes, when it comes to recursion performance - unbound is particularly good. When tuned on a dedicated box for load - it can be phenomenal for recursion.