Selfhosted @lemmy.world Bluesheep @lemmy.world 1mo ago

Help! DNS A Records only ones getting filtered.

I’m pulling my hair out over this. I’ve got a proxmox homelab, an LXC running technitium installed from TTeck’s script.

The DNS server is also doing DHCP for my network. I have an authoritative zone for ‘.lan’

I can get NS, SOA, TXT records from the DNS server, but no A records! The DNS query logs show that it gives an answer, and if I am on the DNS server itself I get an answer, but no other machines on the network hear the reply.

I think this means the DNS server is working properly. There are no FWs in the way as I can resolve other types.

Where else can I look, or how can I diagnose this? I am completely at a loss.

19 comments

Here is how I would diagnose (I'm assuming you have Linux / WSL on a client)

Check the DNS record is actually set (yes do it again)

Do these steps on the client:

dig $domain check which server answered

dig a $domain should give a record

dig a $domain @server to make sure you're querying the right server

If none work, probably network issue (DNS boind to wrong IP, firewall, etc)

If 3 and 5 work but 4 doesn't, your DNS isn't authorative.

If only 5 works DNS settings on the client is wrong.
- You also could do nslookup on Windows
  
  nslookup is available on macOS and most Linux distros as well (and very helpful indeed).
- Thanks for giving it some thought!
  
  I have been testing using dig @192.168.0.249 study.lan
  
  3, 4, and 5 work for TXT, NS and SOA but doesn’t work for A records. I think this rules out a simple network issue?
  
  Just to be sure you do dig A @server $domain (with the "A") and can confirm the following
  
  SERVER is your server
  
  ;; ANSWER SECTION is empty (or doesn't exist)
  
  ;; AUTHORITY SECTION mentions your local DNS server
  
  Also check
  
  dig NS @server $domain
  
  Is your server in the answer section?
Run Wireshark on the client to see if you actually got the reply.
- Thanks for the suggestion, I’ll grab a cap to check.
  
  I’m running tcpdump -i any port 53. I can see the outbound request but not the reply. Will the cap show me anything more?
  
  Do tcpdump host $server instead. Otherwise you will only see the request (the response goes to a different port).
Not sure how technitium works but just from my selfhosting experience are you sure your not hitting dns-rebinding protection somwhere.

In short DNS rebinding stops domains from being resolved to private IP ranges so you don't end up back in your Network when you seem to be resolving a public domain.

I have to set up any domains that resolve locally in my router (which also does DNS and DHCP) but not sure if that's necessary with technitium
What is the connection between your client and server? Is it wireless and going over the router first? Does it work with a direct, wired connection between client and server?

If your connection goes over your router, does your router have a DNS server? What options do you have for DNS config on your router?

Anti Commercial-AI license
How exactly are you testing this from your client, with ping? What are you using to query the DNS?

If you run nslookup from the client

Does the ‘server’ command return the correct DNS server?

Does <A-record>.lan return the expected record?

I’m assuming you’ve run ifconfig to verify your client’s NIC has been assigned the correct DNS via DHCP?
- Thanks for replying, I appreciate the response.
  
  I’m running dig @192.168.0.249 study.lan from my client (a MacBook).
  
  If I run ‘dig @192.168.0.249 study.lan TXT’ I get a correct response (I have added a txt record)
  
  If I run ‘dig @192.168.0.249 lan SOA’ or ‘NS’ I correctly get the records for the zone.
  
  I think this eliminates the possibility of it being a routing error?
  
  Yeah if you can dig a record and received a response it’s not a routing issue.
  
  But aren’t you on the same subnet as your DNS server? There’s no routing happening if you’re on the same subnet which I was assuming.
  
  Even through dig defaults to outputting A records when no other options are specified, I would use the A option anyway just in case:
  
  dig @192.168.0.249 study.lan A
  
  If you use “ping study.lan” do you see it output the A record IP address in the first line of output?
  
  Did you try using nslookup as I described?

19 comments