Nebula lighthouse DNS: who can query which records?

Nebula's lighthouse role does a lot of work that people assume is automatic, and answering DNS is not one of them. Serving names is an optional listener that starts disabled, which is why a host that resolves fine inside the overlay may have nothing to resolve a colleague's laptop at all. Before switching it on, decide who should reach it and which record types you are willing to answer, because those two answers differ.

The listener is optional and off by default

Discovery and DNS are separate services. The lighthouse helps peers find each other, and it can additionally answer name queries about hosts it knows about, but that second part has to be turned on explicitly in the configuration.

Decide the interfaces and networks that should reach the listener before you enable anything. A DNS service that answers on an interface you did not intend becomes a small information leak with no log entry that anybody reads. The decision is much cheaper to make now than to narrow later, after something depends on the wrong answer. Two lines of configuration are easier to reason about than an incident note six months from now.

A records and TXT do not share an audience

The two record types are answered under different conditions, and treating them as one service is the mistake this article exists to prevent.

That asymmetry is deliberate rather than an oversight. A name-to-address mapping is low value to an outsider, while certificate metadata describes the identities in your overlay. Do not carry an assumption from one row to the other just because the same process answers both.

It answers only about the lighthouse own hosts

This is not a general resolver for your office, your cloud VPC or the public internet. The lighthouse answers from host information it has been given, which is also why the feature lives on lighthouse nodes rather than on every peer.

When a name fails that has nothing to do with the overlay, find the zone and resolver that actually own it. Mixing an overlay resolver into a host's general DNS configuration produces failures that look random, because some names resolve and others are answered by nothing at all.

Watch the bootstrap endpoint too. A hostname used to reach the first lighthouse has to resolve through an ordinary path before discovery can depend on it, so a chicken-and-egg problem here looks exactly like a broken overlay. It even reports the same way: a peer that never comes up and no obvious reason why. Check name resolution before you touch certificates, because the ordering catches people who started with the harder half.

Check the bind address, then test from outside

lighthouse.dns.host and lighthouse.dns.port decide where the optional service listens. Review those values alongside the host firewall and the network policy, because a bind address is a statement of intent and not a security control on its own.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

Query from the networks you intend to allow, not from the lighthouse itself. A successful lookup on the lighthouse proves the process is running and tells you nothing about what an outside host can ask, which is the question that actually matters.

Expose it on purpose

Names and certificate metadata are useful operational information, and usefulness cuts both ways. Decide whether the listener should be overlay-only, which record types to permit and who reviews the configuration when it changes.

Then write it down next to the lighthouse settings. The next person to debug a resolution failure will otherwise assume the service was always there. They will also assume it was always reachable from wherever they happen to be testing. One paragraph recording the bind address, the permitted networks and the record types saves that person an afternoon and saves you a message asking why something changed.