How do you discover if the ISP's DNS records have been poisoned?
-
Under setting "Allow DNS server list to be overridden by DHCP/PPP on WAN" it says: "If this option is set, pfSense will use DNS servers assigned by a DHCP/PPP server on WAN for its own purposes (including the DNS Forwarder/DNS Resolver). However, they will not be assigned to DHCP clients."
Does this mean that computers on the LAN will query pfsense's DNS forwarder who will query the ISP's DNS server ONLY?
And therefore all clients are exposed to any poisoning of the ISP's DNS records?
If yes, how do you discover if the ISP's DNS records have been poisoned?
-
why do you not just let pfsense resolve how it does out of the box - which will use dnssec? This is protection from poisoning of domains that are dnssec signed.
-
Alright, what do I do with the above option, enable it or not?
-
Just make sure forwarding mode is disabled in the DNS resolver options, DNSSEC is turned on and Unbound will resolve everything itself and also verify the records for you.
Turn off the "Allow DNS server list to be overridden by DHCP/PPP on WAN" so that nothing in your pfSense or its clients will use external forwarders.
-
I want both 8.8.8.8 and my ISP's DNS service (that is accessible through an ADSL router) to be used simultaneously. And whichever DNS reply comes first, to be returned to pfsense's clients. Don't really know what the above option does, or whether my ISP supports dnssec.
-
Then don't use the ISP forwarders or Google's 8.8.8.8. If you're really concerned about the security and integrity of the DNS records you receive you should use the pure resolver mode.
-
Where will Unbound get DNS records from if pure resolver mode is used?
-
It will query them directly from the authoritative servers of the FQDN, first from one of the servers for the root domain (.), then from the servers for the TLD and then from the next level down the hierarchy and so on. Combined with DNSSEC you can be pretty damn sure that the responses you get are authentic and can be trusted.
-
Where will Unbound get DNS records from if pure resolver mode is used?
This is the part that confuses me.. You do enough research or read something somewhere that scares you about dns poisoning, but don't even know the difference between a resolver and a forwarder?
Why did you change the default configuration of pfsense? Was it not working - out of the box pfsense resolves and uses dnssec..
-
Hi,
Thanks, Ulysses_, your question made me consult https://developers.google.com/speed/public-dns/faq and I was actually surprised.
Normally, I advise not to change any DNS settings used by pfSEnse, and you be having a pretty good security with no effort.But, when using the Forwarder, "DNSSEC" checking will end at the DNS server where you are forwarding to - IF this DNS server is using DNSSEC. I know now hat Google DNS uses DNSSEC, if the information is present. The DNS requests could event use https channels between the DNS server (Google or 8.8.8.8) and your forwarder (pfSense), but I don't know if this is the case with dnsmasq/pfSense/The forwarder. If it is, then, well, even the Forwarder used by pfSense should be considered pretty (very) save.
Btw : DNSSEC isn't a magical solution that always works. See http://dnssec-debugger.verisignlabs.com/dnsviz.net - it can even break an otherwise good work DNS setup.
Why ?
The root level domain should have DS and RRSIG records. This is the case now.
The top level domain name (.net here) should have DS and RRSIG records, which is the case.
The domain name (dnsviz with tld .net) should have DS and RRSIG records - which is the case also.And now the important one : all these DS records should 'sign' from top to bottom all records. This means that the domain name owner should generate a DS "KSK" record that he has to bring to the domain name registrar, typically using a GUI offered by the registrar - or API interface - that is used to setup parameters like the DNS server or the entire zone info, GLUE records and DS records etc. When uploads a DS record, the registrar will sign your DS, itself being signed by the top level domain, and this one signed by the root.
When there is one glitch in the entire process during resolving, your domain name will not resolve anymore => NXDOMAIN in your face.Now add this to the entire story : all these DS keys - even de root one, are rotated (changed) on a regular basis (the root DS rotated at the end 2017). Top level domain DS key are rotated more often, and domain name owners should rotate their DS keys also. The nasty one : you can not swap a new DS key with a new own like that. The problem is global DNS cache latency, the TTL. You'll find on the Internet man, many explanations about the subject.
The issue is : all of these maintenance operations are regular, are done 'by hand' so they involve human interaction - and are considered complicated. Thus : error prone.
Result : the (your) site's domain name can't be resolved anymore and there is no way to restore that situation quick and easy.
So many site owners who maintain their own domain name do not use DNSSEC (yet).Btw : do not take my words for granted. They are just the way I see how DNSSEC works. Remember, I said it was complicated, so they should be considers as "not exact" ;)
I implemented on all my domain names DNSSEC, even the ones I used professionally now (noop, I didn't tell my boss about that one) for the last 18 months now. Rotated many ZSK keys and now I'm up to rotate the KSK key on a test domain (test-domaine.fr). I'm still learning ….
edit : If your ISP uses DNSSEC is rather easy to find out.
Ask them => check their info pages. If they do, they will says so.
Or : setup pfSense using the DNS servers propsoed by you ISP and visit https://dnssec.vs.uni-due.de/
Or : use "dig" from the command line in pfSense using their DNS name server - see https://docs.menandmice.com/display/MM/How+to+test+DNSSEC+validation (pic.org is DNSSEC validated - see http://dnssec-debugger.verisignlabs.com/pir.org )For me, these test all said : Ok (because I'm using the Resolver :D so I have to do nothing and know nothing to be safe).
My ISP doesn't enforce DNSSEC because : it is an ISP. It should transfer to me the Internet as it is : the good part, and the bad part. I do the filtering, they shouldn't, I'm not paying them for that. (btw: some new law changes in the States just changed that ;) - will ISP's over there now filter your requests ? will the enforce DNSSEC ? - I guess not) -
Didn't know the ISP's potentially poisoned DNS is ignored by default.
Let's say you want maximum security when visiting your bank or paypal etc, but do not care at all about security on other sites and only care about performance.
Could put pfsense in a VM with its default DNS setup which is reasonably secure and ignores the ISP.
And have a second pfsense VM that does the fastest thing, ie get IP's of domain names from the ISP and 8.8.8.8 simultaneously and use the IP that comes first. How do I set this up with pfsense's DNS forwarder? Note the ADSL router gives its IP as the DNS server to devices plugged into it via DHCP, so this is offered to pfsense, how do we use this AND 8.8.8.8?
…
-
:P Looks complicated.
What about thsi one : forget about passing your DNS info to big brother (8.8.8.8) - forget about your resolver. Remember : they both resolve for you, and you have to pass the info first - and they give the final answer back to you.
Activate de Resolver - the one that speaks directly to the root DNS …... and your done. Having DNSSEC enforced for free.
It's activated by default - the guys who build pfSense figured out that this was the best thing to have.
