DNS Resolver validation (internal or external firewall)



  • Background: I'm working on setting up a pfSense as the firewall/etc. on my home network, but I have AT&T U-Verse which requires the use their gateway/router. I won't go too much in to detail, but this leaves me with what's called the "DMZplus mode" (AT&T/Pace term) that allows pfSense to be assigned WAN IP address and all traffic to be "pin-holed" (AT&T/PACE term) through AT&T gateway. I've successfully installed pfSense 2.4.5 onto an SG appliance and connected to the internet.

    Question: I'm working on understanding DNS resolvers/forwarders in conjunction with pfSense. To test, I installed pfSense without specifying any DNS servers, assuming this would work by querying root servers only (as resolver not in forwarding mode is the default), but when I run dnsleaktest.sh it returns AT&T servers, which is not what I expected. Should this be what I'd expect? Not the root DNS servers? How do I (or would you) confirm/prove that DNS is functioning exactly as should be expected (even with it connected behind AT&T gateway/router)?

    Testing: Not sure how pfSense behind AT&T gateway/router could (if ever) affect DNS traffic... Like if AT&T would (or could) redirect DNS requests from pfSense... Again, fairly new to this, but while stumbling down this rabbit hole I've been looking into DNSSEC and I think dig/DNSSEC can confirm AT&T is mucking with DNS (at least when I'm not connected behind pfSense). Here's what I've found

    Directly connected to AT&T (not behind pfSense):

    dig www.dnssec-failed.org
    
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
    

    Status should be SERVFAIL so not sure what AT&T is doing here. Running the same dig command behind pfSense (which is still behind AT&T) returns the proper SERVFAIL status though so that's good.

    Another odd thing is dig +trace doesn't work until I use @1.1.1.1 (for example), both directly behind AT&T and pfSense. Not sure why that is.

    dig +trace pfsense.org
    
    ; <<>> DiG 9.10.6 <<>> +trace pfsense.org
    ;; global options: +cmd
    ;; Received 28 bytes from 172.16.0.1#53(172.16.0.1) in 33 ms
    

    Also, I have been trying the packet capture on pfSense, filtering on port 53 and I'm seeing odd IPs like 192.168.34.2 (just made this IP up, did the packet capture yesterday) doing DNS requests, and if I'm remembering correctly is normal and just can't seem to find the right google at the moment, but I'd like to confirm.
    This is expected/normal pfSense behavior right? Why though...? Thinking about firewall rules and such.

    Thank you all so much! This forum is great :)

    Added the link for dnsleaktest script as it seems to return more comprehensive results (sometimes completely different, and working on confirming this, but I think more accurate as well) than the standard dnsleaktest.com, so just thought I'd share.

    Edit: changed trying to change the title, and did some rewording for clarity.



  • Update: Fixed the dig +trace issue, though I don't really understand why, but installing bind fixed the issues. Can now run a trace from directly behind AT&T and behind pfSense (behind AT&T).

    Also, here are some of the one-liners I've been using in my research. Maybe they'll be of some use.

    wan_ip="$(curl -s https://www.pfsense.org/ip | xmllint --format --xpath 'string(//body)' - 2>&1 | grep -Eo "${valid_ipv4}")"
    
    active_ipv4_interface="$(ifconfig | pcregrep -M -o '^[^\t:]+:([^\n]|\n\t)*status: active' | grep -Eo "(en5|en0)" | sort | uniq)"
    
    # validate DNSSEC, should see status: NOERROR and flags: ... ad flags: do
    dig +dnssec +noall +comments icann.org | grep -Eo "flags:*.+;|status:*.+,"		                        
    
    valid_ipv4="(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)"
    ap="$(netstat -nr | grep default | grep -Eo "${valid_ipv4}")"
    
    dig +dnssec +noall +comments dnssec-failed.org | grep -Eo "(flags:*.+;|status:*.+,)"       # should return SERVFAIL, and no flags: ad
    

    hopefully these might help someone. And if any has some scripts or knowledge about this, casually or otherwise, please let me know. Cheers!



  • I saw this ones or twice :

    @MilesMorales said in DNS Resolver validation (internal or external firewall):

    dig +trace pfsense.org

    ; <<>> DiG 9.10.6 <<>> +trace pfsense.org
    ;; global options: +cmd
    ;; Received 28 bytes from 172.16.0.1#53(172.16.0.1) in 33 ms

    "dig" worked, but adding the +trace option silenced it completely, there were no results except for these 3 lines.

    @MilesMorales said in DNS Resolver validation (internal or external firewall):

    installing bind fixed the issues

    Did you also uses bind to resolve ? Or just installing it without activation ?

    This is one of the rare situation where a reboot of pfSense restored the dig + trace functionality. I never investigated for a reason, I've still a note for myself to find out what happened.

    Btw : System > General Setup > DNS Server Override isn't set, right ?



  • @Gertjan thanks for the reply man. And just installing it without activation. dig +trace (on macOS) wasn't working whether it was behind pfSense or not (albeit still on the same network, kinda, see background).. Not sure if any of this helps, but I'm not sure it's the same issue then. And yeah, plan to reinstall everything here once I get it figured out (including macOS,) and if you want, and it happens again, and I can properly look into it (not just get lucky), I'll let you know. Ended up installing after realizing I needed it for delv commands..

    Yes, DNS Server Override is unchecked.

    Also, one thing, that's assumed, but not specifically mentioned in my original post, RFC1918 is not blocked from entering the WAN with this internal firewall setup (which is partly why I'm using this internal setup as an excuse to look into all of this.)


Log in to reply