Setup DNS over TLS on pfSense 2.4.4 p2 - Guide



  • Getting aware that more and more DNS providers offer DNS over TLS, I decided to try a setup with my pfSense.
    As the netgate guide for DNS over TLS with pfSense does not cover the latest pfSense release 2.4.4 p2, I’d like to share my experience and setup.

    In my case, I use the Quad9 DNS servers.

    Step 1:
    Ensure Quad9 DNS servers are used. Go to System > General Settings and under DNS servers add IP addresses for Quad9 DNS servers and select the WAN gateway.
    Make sure the DNS Server Override is unchecked as we don’t want the Quad9 DNS servers being changed by the ISP.

    0_1547986771355_1.jpg

    Step 2:
    The DNS resolver needs to be changed accordingly. Navigate to Services > DNS Resolver.
    Make sure the DNS resolver is enabled at all. Verify that you selected ALL network interfaces. Enable DNSSEC Support, DNS Query Forwarding and check the usage of SSL/TLS.

    UPDATE: Leave DNSSEC UNCKECKED as it's simply no neccessary as pointed out by @johnpoz in his post below - thx for that!

    With the DNS Query forwarding the Quad9 DNS servers of step 1 will be used.

    0_1547986815803_2.jpg

    Et voila, that’s it!

    Step 3:
    The setup is pretty straight forward, but no setup without verification.

    Therefore go to Diagnostics > States, filter for the Quad9 DNS Server IP (9.9.9.9) and you will see that the DNS protocol is now TCP (whereas default DNS on port 53 is UDP) and the port is 853.
    Don’t get confused here by my interface name (TGINTERFACE). I use a VPN provider and the DNS queries are not send through WAN, but the VPN interface.

    0_1547986849160_3.jpg

    An additional verification is to use Package capture. Go to Diagnostics > Packet Capture. Select your interface (probably WAN if you do not use a VPN provider or something similar) and enter for example the port 853.
    Press “start” and browse a website. Hit the stop-button and you will see a packet capture looking similar to this.

    0_1547986925633_7.jpg

    As you can see, the DNS queries go to the Quad9 DNS Servers over port 853.
    I also put in the default DNS port 53 to double-check if queries go the default port. The packet capture came up empty, so everything looks fine.

    As I am a very careful person, I also added some floating firewall rules to prevent DNS resolution over port 53 and I only allow DNS resolution over Quad9 server using port 853.
    I don’t know if this is actually necessary.

    0_1547986957027_8.jpg

    In a second step, we are going to verify the DNSSEC support. Simply go to https://dnssec.vs.uni-due.de/ and hit “start test”.

    Now if everything works as planned, the little guy gives us a thumb up

    0_1547987020018_5.jpg

    Otherwise you’ll get a:

    0_1547987036758_6.jpg

    Make sure to use private browsing or clearing the cache during toggling DNSSEC on/off and testing.

    That’s it.

    Let me know if I missed anything here. I'd appreciate as well some feedback on the floating rules that block DNS over port 53. I really don't know if this is necessary. If I remembered right I saw some queries going to port 53 even though I had TLS activated. I just tried to reproduce this now, but the package capture on port 53 keeps being empty while I deactivated the floating rules.



  • @laus3r said in Setup DNS over TLS on pfSense 2.4.4 p1:

    Let me know if I missed anything here. I'd appreciate as well some feedback on the floating rules that block DNS over port 53. I really don't know if this is necessary. If I remembered right I saw some queries going to port 53 even though I had TLS activated. I just tried to reproduce this now, but the package capture on port 53 keeps being empty while I deactivated the floating rules.

    I remember now the reason for the floating rule for DNS over port 53 - DNS leak prevention! :-)

    Making sure that absolutely no DNS queries go out on port 53 and only over TLS on port 853, DNS leaks are prevented. This aspect is especially important if you use a VPN provider.
    You can check for DNS leaks on several sites, for example
    https://www.dnsleaktest.com
    http://dnsleak.com/

    When running a test, you should never see your ISP's WAN IP. If that's the case you have a dns leak.


  • LAYER 8 Global Moderator

    You do understand that the dnssec if your going to forward is pointless right... Using quad9 will pass the dnssec test you pointed to be it you enable dnssec or not... Since they do dnssec without you having enable it..

    Just setup your end machine to point to quad9 for dns... Then run that test you linked too.

    If your going to forward in unbound, there is ZERO reason to checkbox the dnssec. Resolvers validate dnssec, not forwarders.

    dnssec works

    $ dig @9.9.9.9 www.dnssec-failed.org
    
    ; <<>> DiG 9.12.3-P1 <<>> @9.9.9.9 www.dnssec-failed.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5771
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; Query time: 24 msec
    ;; SERVER: 9.9.9.9#53(9.9.9.9)
    ;; WHEN: Wed Jan 23 05:50:43 Central Standard Time 2019
    ;; MSG SIZE  rcvd: 50
    

    non dnssec dns server.

    $ dig @4.2.2.2 www.dnssec-failed.org
    
    ; <<>> DiG 9.12.3-P1 <<>> @4.2.2.2 www.dnssec-failed.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17404
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 8192
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; ANSWER SECTION:
    www.dnssec-failed.org.  7200    IN      A       69.252.193.191
    www.dnssec-failed.org.  7200    IN      A       68.87.109.242
    
    ;; Query time: 34 msec
    ;; SERVER: 4.2.2.2#53(4.2.2.2)
    ;; WHEN: Wed Jan 23 05:51:46 Central Standard Time 2019
    ;; MSG SIZE  rcvd: 82
    

    So go ahead and remove your checkbox from dnssec in unbound, and try your test again.. Having your forwarder do dnssec is pretty freaking pointless, and only causes unneeded dns traffic.



  • so your custom options within DNS resolver is left.. blank?

    i am still following the directions posted from https://www.netgate.com/blog/dns-over-tls-with-pfsense.html



  • @bcruze this custom option was necessary on previous version of pfSense. Now you have a checkbox for this. "Use SSL/TLS for outgoing DNS Queries to Forwarding Server"



  • @johnpoz said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    You do understand that the dnssec if your going to forward is pointless right... Using quad9 will pass the dnssec test you pointed to be it you enable dnssec or not... Since they do dnssec without you having enable it..

    Just setup your end machine to point to quad9 for dns... Then run that test you linked too.

    If your going to forward in unbound, there is ZERO reason to checkbox the dnssec. Resolvers validate dnssec, not forwarders.

    dnssec works

    $ dig @9.9.9.9 www.dnssec-failed.org
    
    ; <<>> DiG 9.12.3-P1 <<>> @9.9.9.9 www.dnssec-failed.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5771
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; Query time: 24 msec
    ;; SERVER: 9.9.9.9#53(9.9.9.9)
    ;; WHEN: Wed Jan 23 05:50:43 Central Standard Time 2019
    ;; MSG SIZE  rcvd: 50
    

    non dnssec dns server.

    $ dig @4.2.2.2 www.dnssec-failed.org
    
    ; <<>> DiG 9.12.3-P1 <<>> @4.2.2.2 www.dnssec-failed.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17404
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 8192
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; ANSWER SECTION:
    www.dnssec-failed.org.  7200    IN      A       69.252.193.191
    www.dnssec-failed.org.  7200    IN      A       68.87.109.242
    
    ;; Query time: 34 msec
    ;; SERVER: 4.2.2.2#53(4.2.2.2)
    ;; WHEN: Wed Jan 23 05:51:46 Central Standard Time 2019
    ;; MSG SIZE  rcvd: 82
    

    So go ahead and remove your checkbox from dnssec in unbound, and try your test again.. Having your forwarder do dnssec is pretty freaking pointless, and only causes unneeded dns traffic.

    @johnpoz , yeah you are 100% right. Thx for the explanation. I'll update the post accordingly and put the DNSSEC-checkbox to "Unchecked"



  • I have a couple of questions,

    Is it still possible to use internal DNS on port 53 when you use this setup, and I also would like to know on what interface the floating rules are applied?



  • @no_jah said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    I have a couple of questions,

    Is it still possible to use internal DNS on port 53 when you use this setup, and I also would like to know on what interface the floating rules are applied?

    yes, it is possible to use port 53. Just make sure that the port is open.

    Regarding the interface: I use a VPN connection for my whole traffic. That's why the interface in my case is called TGINTERFACE and not WAN. The most common setup is to use the WAN interface for the internet traffic. If this is the case for you, select the WAN interface.

    Cheers



  • This post is deleted!


  • @bcruze said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    why isn't the top option checked : Respond to incoming SSL/TLS queries from local clients

    well, you could check it. I simply wasn't aware about that option, but it could make sense depending on your config

    @bcruze said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    i've followed this step again. and states still shows :

    (192.168.1.246:40971) -> 1.1.1.1:53
    that is somehow strange. Do you use a local config maybe for this client? can you post it please?



  • @LaUs3r
    When I turn on the floating rule to block port 53 I can do google searches but can't get to any other websites. If I disable the port 53 blocking rule then I can get to any site but the pfSense packet capture report shows traffic on port to 8.8.8.8. I'm really not sure where Googles DNS is coming from. Do you have any suggestions on how I might change the port 53 blocking rule?

    Packet Capture on port 53 give me:
    15:23:28.505900 IP 75.xxx.xxx.xxx.32041 > 8.8.8.8.53: UDP, length 33
    15:23:28.535878 IP 8.8.8.8.53 > 75.xxx.xxx.xxx.32041: UDP, length 49

    365f474f-7186-4fcb-b8bc-6da26c63edf4-image.png

    f9e6214b-0768-40ec-9ee2-5a32d8f40582-image.png



  • @LaUs3r

    With this rule why would I be seeing any port 53 traffic with packet capture?

    0157109a-9e6b-4705-a673-d46b9c37c5ee-image.png


  • LAYER 8 Global Moderator

    packet captures have nothing to do with what actually shows up on the interface.. Just tells pfsense what to do with traffic sees on the interface, either allow it and process it, or block it (drop it without doing anything with it).



  • @johnpoz so you don't agree with @LaUs3r that Package Capture can be use to verify that ALL DNS traffic to the outside world is going out over TLS (port 853) and there is no leakage on port 53? Per the guide above, I'm seeing 9.9.9.9:853 TCP traffic with Diagnostic | States and 9.9.9.9:853 traffic with Diagnostic | Packet Capture. But I am also seeing 8.8.8.8:53 traffic.

    Per your comment just because I'm seeing some 8.8.8.8 traffic with packet capture doesn't mean it's going out on the WAN?
    Packet Capture on port 53 give me:
    15:23:28.505900 IP 75.xxx.xxx.xxx.32041 > 8.8.8.8.53: UDP, length 33
    15:23:28.535878 IP 8.8.8.8.53 > 75.xxx.xxx.xxx.32041: UDP, length 49
    .
    .
    .

    Is there a feature in pfSense that I can confirm I have DNS over TLS with no leakage or should I just assume if the floating firewall rule I've shown above will assure that no port 53 traffic is getting out of my network.

    Thanks for all you comments.

    p.s. Could I setup the floating DNS port 53 blocking rule on either the WAN or LAN interface, assuming I didn't care about my DMZ?


  • LAYER 8 Global Moderator

    Huh? Where did I say that? My point is you can block all day on LAN, and then sniff on Lan and see packet captures with it.

    You can block all day on LAN for 53, and you could still see outbound on your wan for 53... Maybe pfsense itself was set to directly ask 8.8.8.8 in its general settings vs JUST loopback..

    As to floating rules for 853.. Why would think you need those in the first place?

    And you can not stop pfsense from talking outbound, you can put rules all day long on floating tab.. Traffic generated by pfsense can not be blocked... There are HIDDEN rules.. So you could create an any or out rule on your wan for 53 in floating, make it quick - and still pfsense would be allowed out.

    So why don't you actually open up the sniff of that to 53 traffic and see what the query was actually for.. Which should give you some clue to its origin.

    But yes you can sniff on your wan, for port 53 to catch any traffic that was going out of your network to validate your setup is working..



  • @johnpoz said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    You do understand that the dnssec if your going to forward is pointless right... Using quad9 will pass the dnssec test you pointed to be it you enable dnssec or not... Since they do dnssec without you having enable it..

    Just setup your end machine to point to quad9 for dns... Then run that test you linked too.

    If your going to forward in unbound, there is ZERO reason to checkbox the dnssec. Resolvers validate dnssec, not forwarders.

    dnssec works

    So go ahead and remove your checkbox from dnssec in unbound, and try your test again.. Having your forwarder do dnssec is pretty freaking pointless, and only causes unneeded dns traffic.

    Does the same hold true DNSSEC is unnecessary when in forwarding mode for cloudflare 1.1.1.1 ?



  • Rule of thumb : when forwarding, dnssec is useless/won't work/has no sense.



  • @LaUs3r

    Having DNSSEC enabled not only is not necessary but it breaks the function of TLS.

    Cloudflares DNS checker shows it not working if DNSSEC is running at least.


  • LAYER 8 Global Moderator

    having dnssec enabled shouldn't break dot.. But when your forwarding - dnssec is pointless.. If you forward and where you forward their resolver is doing dnssec, you get it by default... If not, then you asking for it doesn't get you anything..

    When you forward - dnssec should be OFF, no matter how you look at it.


  • Rebel Alliance Developer Netgate

    DNSSEC is for validating authenticity (prevent spoofing, hijacked authoritative nameservers, etc).

    DNS over TLS is for encrypting transport (privacy).

    They do different things and are both are useful, especially together, for increased security and privacy.

    There is no reason you can't run both, unless whatever you are forwarding to does not support one or the other.


  • LAYER 8 Global Moderator

    @jimp said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    There is no reason you can't run both, unless whatever you are forwarding to does not support one or the other.

    This could be confusing.. if your forwarding - then you do not need to enable dnssec on the forwarder.. Its makes no sense to do so.. Its just going to cause extra traffic in your dns query. If where your forwarding is doing dnssec - the forwarder doesn't matter for any sort of dnssec settings. The resolver your forwarding too either does dnssec or it doesn't


  • Rebel Alliance Developer Netgate

    Your forwarder can validate DNSSEC for you, provided it supports that function. Assuming you trust the server you are forwarding to.


  • LAYER 8 Global Moderator

    The resolver would of have already validated it if doing dnssec, if it didn't validate it wouldn't give you an answer..

    It is pointless to have a forwarder do anything with dnssec.. Unless you want some eyecandy in say pihole or something on which records were validated via dnssec and which were not. But makes no difference - if the resolver is running dnssec, and something doesn't validate - you wouldn't get an answer.


  • Rebel Alliance Developer Netgate

    Maybe in a perfect world if the upstream forwarder unilaterally did DNSSEC for everything. But in reality, if you don't request validation, it won't outright deny the query like that. At least with some forwarding services like Google public DNS, you have to send the AD/DO flag in the query or they won't drop responses that fail DNSSEC tests.


  • LAYER 8 Global Moderator

    no that is not the way a dnssec resolver works.

    here I asked quad 9 for a fqdn that fails validation

    ; <<>> DiG 9.14.4 <<>> @9.9.9.9 www.dnssec-failed.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39214
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; Query time: 230 msec
    ;; SERVER: 9.9.9.9#53(9.9.9.9)
    ;; WHEN: Thu Sep 26 08:02:01 Central Daylight Time 2019
    ;; MSG SIZE  rcvd: 50
    

    I did not ASK for any dnssec - it just does it..

    Now if I ask a non dnssec resolver - say 4.2.2.2, I get an answer

     <<>> DiG 9.14.4 <<>> @4.2.2.2 www.dnssec-failed.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38029
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 8192
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; ANSWER SECTION:
    www.dnssec-failed.org.  7200    IN      A       69.252.193.191
    www.dnssec-failed.org.  7200    IN      A       68.87.109.242
    
    ;; Query time: 38 msec
    ;; SERVER: 4.2.2.2#53(4.2.2.2)
    ;; WHEN: Thu Sep 26 08:03:45 Central Daylight Time 2019
    ;; MSG SIZE  rcvd: 82
    

    google does dnssec

    ; <<>> DiG 9.14.4 <<>> @8.8.8.8 www.dnssec-failed.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25753
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; Query time: 80 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Thu Sep 26 08:04:33 Central Daylight Time 2019
    ;; MSG SIZE  rcvd: 50
    

    https://www.internetsociety.org/blog/2013/05/confirmed-googles-public-dns-now-performs-dnssec-validation-for-all-queries-by-default/

    you do not have to ask - when you forward asking for dnssec is pointless!!! Other than maybe your tool providing some eyecandy on which ones pass and which ones don't have it.


  • Rebel Alliance Developer Netgate

    I recall digging into it a while back and you had to have DNSSEC enabled to get that behavior (at least from Google public DNS servers). I didn't think it was that long ago, though. Maybe it was before 2013. I still wouldn't say it's pointless to ensure you are requesting it.

    DNS over TLS still only covers privacy and first-hop validation (Assuming you are checking the hostname/cert), though.


  • LAYER 8 Global Moderator

    no its pointless.. Your forwarding, how is your forwarding even going to validate the records it gets back.. Does it have the anchors? How is it actually going to do the validation?

    So I ask 4.2.2.2 +dnssec - still get a freaking answer. I get back the rrsig

    ; <<>> DiG 9.14.4 <<>> @4.2.2.2 www.dnssec-failed.org +dnssec
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44796
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags: do; udp: 8192
    ;; QUESTION SECTION:
    ;www.dnssec-failed.org.         IN      A
    
    ;; ANSWER SECTION:
    www.dnssec-failed.org.  7200    IN      A       69.252.193.191
    www.dnssec-failed.org.  7200    IN      A       68.87.109.242
    www.dnssec-failed.org.  7200    IN      RRSIG   A 5 3 7200 20191002174442 20190925143942 44973 dnssec-failed.org. cJnvSoQfMtWHg4KWySkDAEaHaqtcw+BlHNC2+MuT1BSJDpn5fv3fIEyG HuPYJ4Pd9N38QgBDA4Bcdfc0O/P5qzvP6+ixCwLNJ9FppRrNVuPG6QCB pIApBzleHvfwKPZUQ1FKXjOaCEb/vQJhJ/QvwSSmz4LLF3sh0M3s8nvK hK8=
    
    ;; Query time: 96 msec
    ;; SERVER: 4.2.2.2#53(4.2.2.2)
    ;; WHEN: Thu Sep 26 08:10:46 Central Daylight Time 2019
    ;; MSG SIZE  rcvd: 259
    

    Means nothing.. How is it validated by the forwarder? If the forwarder did some sort of validation? You clearly trust this where you forwared, and you picked it to do dnssec for you.. What is the point in trying to doublecheck what it sends you.. It could send you anything it wanted to be honest..

    If you want dnssec, run your own resolver (unbound) if you want to forward and have dnssec, then pick a NS you forward to that does dnssec for you. Its that simple - if you forward there is no reason for the forwarder to ask about dnssec. If you want to forward with dot or doh and dnssec - pick a NS to forward to that does what you want to use. Enabling dnssec on a forwarder, that is forwarding to something that doesn't do dnssec is pointless. Having dnssec enabled on your forwarder using forwarding to a resolver that does dnssec is pointless.

    If you forward to something that is suppose to be doing dnssec, and you get back an answer for something that should be failing dnssec - then where you forwarding to is broken, so you asking for dnssec is not going to fix their broken setup even if you did get back rrsig for that record..


  • Rebel Alliance Developer Netgate

    It's not about the client validating it locally but about telling the server "yes, I would like this validated" if the server does so conditionally. Sure, you can pick a forwarder that does what you want 100% of the time but that may not be in your control.

    It's not an absolute situation. You can't say it's worthless 100% of the time because you do not know what the servers are doing. Sure, the ones you checked behave that way, but that doesn't mean everyone's always will. You can't make those assumptions.


  • LAYER 8 Global Moderator

    Name one public ns you can ask for dns, that doesn't do dnssec unless you ask it... There is no such animal that I am aware of.. But ok - that is one scenario where could make sense - but wouldn't it just be better solution to just use a forwarder you "know" is doing dnssec.. Which pretty much all the major players are doing now.. Some even have specific IPs you can use that don't do it, etc.But their normal IPs do it out of the box.

    If the ns your forwarding to doesn't do dnssec unless you ask it, how do you know its doing it even when you ask it or doing it correctly? You can not assume it would do such a thing.

    If you want to turn it on, have it - it shouldn't break anything... I just do not see a point in doing such a thing, ie pointless ;)

    If I hire a doorman (that I TRUST) to check ids to make sure they are valid.. And his duty is to validate them (he is doing dnssec).. What is the point in asking him to do it? Oh can you write down the info and send it to me as well, so I can double check your work (so you don' trust him?).. But since he is the one writing down the info on how he validated the ID, how are you to know that its not valid from looking at that info... He could send you anything he wants to send you..

    If I hire a doorman, but he only validates the ids if I ask him - so I ask him every time there is an ID to check... He is a pretty shitty doorman, why wouldn't I just hire one that does that already - so I don't have to ask him..

    If I hire a doorman that doesn't check IDs, but if I ask him he will pass on the info he has for me to check it, but I don't have a valid way to check it - what is the point?


  • Rebel Alliance Developer Netgate

    You are assuming people always forward to public DNS servers, too. Too many assumptions about too many things. That's not the way the real world works for everyone all around the globe.

    You can qualify your statement and still be correct: Yes, if you know your upstream forwarder is doing DNSSEC properly 100% of the time for all queries, then you most likely do not need to set DNSSEC locally.

    But you cannot assume you know how everyone's upstream servers behave.


  • LAYER 8 Global Moderator

    And you think these users do? Are they forwarding to their own resolving NS, then they should set it to do dnssec if that is they want.

    So your scenario here is to turn it on - because you don't know it might do something? Is that what your saying?

    You either understand how your upstream NS works - your forwarding to it! Or you don't... Turning dnssec on hoping it does something is again - pointless!!


  • Rebel Alliance Developer Netgate

    I'm saying you can't always say it's pointless. The user has to make that determination based on the behavior of their chosen forwarding server. Is it typically unnecessary? Probably. But that's between the user and their DNS servers.


  • LAYER 8 Global Moderator

    @jimp said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    But that's between the user and their DNS servers.

    Valid point. But all I can do is base my recommendation on experience with dns.. And in all of that experience I have never seen a scenario where it makes sense to do dnssec if your forwarding... Is it possible there is some odd ball setup where it might do something. Sure ok..

    Your assuming the users actually understand what they are doing... They don't or they wouldn't be here asking ;) And to be honest if they are doing some odd ball setup where forwarding and asking for dnssec actually does something worthwhile.. I would tell them they are doing it wrong ;) Why not just forward to NS that actually does dnssec without asking it to do it ;)

    If a NS doesn't do dnssec unless you ask for it, how could it serve you up stuff from cache? Since if it didn't do dnssec that cache info is not validated... So It can not serve it up to anyone that asks for dnssec, It would have to do a fresh resolve. So its either doing dnssec all the time, so it only places stuff that validates in its cache, or does not have any dnssec set on it.. Or its not... So asking some NS to to do dnssec that isn't doing it all the time makes no sense really.. Because it would not be able to use its cache - which is really the point of forwarding. If your just to resolve anything you ask and do dnssec on it - might as well just run my own resolver and get the info directly, etc.

    Lets just agree to disagree here I guess. I will give you the point that we can not know all possible scenarios that a user might be doing, and we are only assuming.. But I for the life of me can not fathom an actual real world scenario were it would make any sense to ask for dnssec of a NS I am forwarding too that doesn't already do it anyway. So no reason to ask in the first place.



  • I did these same steps but used 1.1.1.1 and 1.0.0.1. My connection states show its TCP 853 traffic to 1.1.1.1.
    But when I use cloudflare’s tester, it shows it failed. Ignore the 192.168.1.11, that’s a hard coded machine I have to fix.

    Settings: https://imgur.com/gallery/2gbd2Il

    Fail: https://imgur.com/gallery/xeclJ0W


  • LAYER 8 Global Moderator

    How would they know how you talked to 1.1.1.1 - the test is not valid unless your talking to their dns..

    They can only test that your encrypted or not encrypted to dns if your actually talking to them for dns.. That test should say NA unless your talking to them.. Not that your unsecured - they have no clue what port or protocol or anything on how you talked to 1.1.1.1

    This is what it should say

    securedns.jpg



  • For some reason, now it shows Secure DNS. Not sure what changed to make it do it or why yours is showing a question mark....

    works.PNG



  • I can't tell by all of the different posts... but what block rule would you use to block any 53 traffic just on the lan network from going outbound to make sure your not leaking? I have a separate lan I still want 53 traffic to work.


  • LAYER 8 Global Moderator

    If you don't want 53 outbound, then block that.. Rules are evaluated top down, first rule to trigger wins.. No other rules are evaluated..

    Allow to what you want 53 to go to, below block 53 to anything else. Its that simple. Do you really need a picture?

    here
    blockdns.jpg

    I allow dns to pfsense address, and my pihole (that sits on another segment)
    I then block any other access to 53, and 853 (dot)..

    The top rule there blocks access to what the doh servers resolve too for doh, I have all of the known doh servers resolve to that IP.. This an attempt to block access to doh, since doh really needs to use a url to be used, and I have all of their names setup to resolve to that IP.

    example snip of some of them. There are many more.

    local-data: "cloudflare-dns.com. 120 IN A 172.19.19.19"
    local-data: "dns.quad9.net. 120 IN A 172.19.19.19"
    local-data: "dns9.quad9.net. 120 IN A 172.19.19.19"
    local-data: "dns10.quad9.net. 120 IN A 172.19.19.19"
    local-data: "doh.opendns.com. 120 IN A 172.19.19.19"
    local-data: "doh.cleanbrowsing.org. 120 IN A 172.19.19.19"
    local-data: "dns.nextdns.io. 120 IN A 172.19.19.19"
    

    The plan is to also create an alias with all the know IPs of the doh servers, and directly log any traffic to them on 443 - but haven't set it up yet.

    For them to say your using secure dns, means your asking them directly! Its pretty clear there.. where it states "you are using encrypted transport with 1.1.1.1"



  • Hi all,

    late to the thread, but related to my current issue.

    First off, to block all outgoing traffic to port 53, I have a floating rules to allow lan etc in on 53 (quick), then the next rule to block all 53 traffic including on WAN "OUT". This blocks everything including packets originating from pfsense itself. I have logging turned on, so any escapees show up. The main thing to note is that floating rules can block outgoing traffic on a network, unlike normal rules which can only block incoming so are no good at blocking connections originating from pfsense.

    I have set up a NAT on the LAN to force any attemped UDP:53 from the lan to use pfsense. I have a nvidia shield which insists on using 8.8.8.8 udp 53.

    I have set up DNS resolver to forward to 1.1.1.1 etc using TLS etc.

    Now the problem I see is occasionally PFSense is sending out requests to UDP 53. I unblocked my floating-WAN-OUT-53 rule (or changed it to a pass ) and use a looping shell script and sockstat to locate the culprit (Please tell me a more elegant way to do this). I found things like ntpd and ntopng were causing this.

    Now /etc/resolv.conf shows:
    nameserver 127.0.0.1
    nameserver 1.1.1.1
    nameserver 1.0.0.1

    I am thinking that local pfsense services are using the /etc/resolv.conf and sometimes not going to 127.0.0.1, in which case a direct UDP to 53 is being used.
    It seems to me that the resolv.conf is populated from the entries in system/generalsetup/DNS server settings/DNS servers, but idealy the forwarding resolver should be using a different list. i.e. resolve.conf: 127.0.0.1 and forwarding 1.1.1.1, 1.0.0.1 with TLS etc.

    My solution is to go back to the "Custom Settings" as outlined in "https://www.netgate.com/blog/dns-over-tls-with-pfsense.html" and remove all entries in general setup/DNS servers (leaving only 127.0.0.1 in resolv.conf)

    I guess the other option is to just keep blocking outgoing port 53.

    Comments please.

    Duncan



  • @duncan-young said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    I am thinking that local pfsense services are using the /etc/resolv.conf and sometimes not going to 127.0.0.1, in which case a direct UDP to 53 is being used.

    That means that these services have some kind of resolver integrated.
    In that case you should set up these services to use the local unbound' facilities.
    But, as far as I know, such kind of services are not used by pfSense.
    Some package ?

    @duncan-young said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    PFSense is sending out requests to UDP 53

    Do not forget to filter TCP:53 requests.

    @duncan-young said in Setup DNS over TLS on pfSense 2.4.4 p2 - Guide:

    but idealy the forwarding resolver should be using a different list. i.e. resolve.conf: 127.0.0.1 and forwarding 1.1.1.1, 1.0.0.1 with TLS etc.

    Noop.
    unbound, as any other local resolver/forwarder uses the system file /etc/resolv.conf
    Check also your main unbound config file, /var/unbound/unbound.conf


Log in to reply