Ask
25

What is the correct way to get local hostname resolution when a filtering resolver is in the path?

I put a filtering DNS resolver on my network and now local devices cannot be reached by name. Before, my router answered for local names; now everything asks the filter, which knows nothing about my house.

I have seen several approaches suggested — pointing the filter back at the router, adding entries by hand, using a specific local domain — and I cannot tell which is the right one rather than the one that happened to work for somebody.

What is the arrangement that is actually correct?

4 answers Share
Report

Answering anonymously — a moderator will review it first.

  • @dns_filter_devrim · 4d ago

    The problem in one sentence: you replaced the resolver that knew about your network with one that does not, and local names were only ever working because the router was answering them.

    Routers typically learn hostnames from the address leases they hand out and answer for those names. Point everything at a filter instead and that knowledge is bypassed.

    The three arrangements, and which is correct depends on where the address leases are handed out:

    1. The filter also hands out addresses. Then it learns the names itself and answers for them, and the problem disappears entirely. This is the cleanest arrangement and it is why the option exists. The cost is that your resolver is now also responsible for handing out addresses, so if it is down, nothing new can join the network.

    2. The router hands out addresses, and the filter forwards local names to it. Configure the filter to send queries for your local domain to the router. Correct, and it keeps the two jobs separate.

    3. Static entries in the filter. Correct only for things that never change — the server, the printer, the hub.

    30
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @hub_hazal · 4d ago

    One thing to check when it works from some devices and not others: clients that ignore your resolver.

    Phones and browsers increasingly use encrypted DNS to a provider of their own choosing by default. Those queries never reach your filter, so local names fail and filtering also silently stops working on that device.

    The fixes are per-platform — turning off private DNS on a phone, disabling secure DNS in a browser, or advertising your own encrypted resolver. Worth knowing before concluding your configuration is wrong, because it looks identical to a misconfiguration and it is the client deciding not to ask you.

    22
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @lan_levent · 2d ago

    The detail that makes any of these work reliably, and which most guides skip: use a proper local domain and be consistent about it.

    Give the network a domain, hand it out with the address leases, and refer to machines as thing.yourdomain rather than as bare names. Bare single-label names are resolved by a mixture of mechanisms depending on the client and are the reason it works on one device and not another.

    What to use: a subdomain of a domain you actually own is the safest. Failing that, .internal is now reserved for exactly this. Avoid .local, which belongs to multicast discovery and will conflict, and avoid inventing a name that might become a real top-level domain.

    26
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @desktop_dilan · 2d ago

    For a handful of important machines, there is a fourth option worth mentioning: give them fixed addresses and stop depending on name resolution for the things that matter.

    The hub, the server and the printer having addresses that never change means that when DNS is broken — and at some point it will be — you can still reach the things you need to fix it. That has saved me more than once, and it costs nothing.

    14
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report