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.

  • truthfultemporarily@feddit.org
    link
    fedilink
    English
    arrow-up
    7
    ·
    edit-2
    13 小时前

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

    1. Check the DNS record is actually set (yes do it again)
    2. Do these steps on the client:
    3. dig $domain check which server answered
    4. dig a $domain should give a record
    5. 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.

    • Bluesheep@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      12 小时前

      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?

      • truthfultemporarily@feddit.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        8 小时前

        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?

        • Bluesheep@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          23 分钟前

          Yes, everything looks right. I moved dhcp resolution from the router to technitium recently, but hadn’t set up local resolution.

          I’m currently thinking the router is the culprit. Here in the UK there are lots of forum posts complaining about the Virgin Media gear. Nothing specifically describes my problem but I’m going to try a new router over the weekend.

          • truthfultemporarily@feddit.org
            link
            fedilink
            English
            arrow-up
            1
            ·
            17 分钟前

            Seems weird to me, the router would need to do deep packet inspection of DNS and selectively block specific ones. It feels more like you’ve set up your DNS to do forwarding instead of resolution. Can you post a network diagram and the DNS config?

    • Bluesheep@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      12 小时前

      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?

  • hemmes@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    13 小时前

    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?

    • Bluesheep@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      12 小时前

      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?