Authoritative records for local names#

You will end up with the router answering for names of your own — nas.example.com resolving to an inside address for every client on the LAN, without touching a public DNS zone. This is also the good answer to "it works from outside but not from my desk": give the service a name that resolves to its inside address, and the LAN never touches NAT at all.

Before you start#

The operator role and a licence.
The forwarder configured, and the LAN pointed at it.
A domain to be authoritative for. Use one you own, or a name that cannot collide — not .local, which belongs to mDNS.

Step 1 — Add a record#

Network → DNS → + Add record.

set service dns forwarding authoritative-domain example.com records a nas address 192.0.2.10

The record type decides the leaf, and getting it wrong is the mistake the editor exists to prevent:

Type	Leaf	Value
`a`	`address`	An IPv4 address
`aaaa`	`address`	An IPv6 address
`cname`	`target`	Another name
`ns`	`target`	A name server
`txt`	`value`	Text
`mx`	`server`	A mail server

The name @ means the domain itself.

set service dns forwarding authoritative-domain example.com records cname www target nas.example.com
set service dns forwarding authoritative-domain example.com records txt @ value 'v=spf1 -all'

Step 2 — Or use a static host mapping#

For a single name outside a zone you are authoritative for, there is a shorter form that lives under system rather than under the resolver:

set system static-host-mapping host-name nas.example.com inet 192.0.2.10

This is what the OPNsense importer writes for the old router's static host entries. Use the authoritative domain when you are answering for a whole zone; use a static host mapping for one name.

Step 3 — Split-horizon, deliberately#

If a name exists publicly and you want it answered differently inside, an authoritative domain here overrides the public answer for anyone using this resolver. That is the mechanism, and it is the right way to make a published service reachable from the LAN without hairpinning.

The cost is that the two answers can drift. Write down that the router holds an authoritative copy, because the day the public address changes, this is where the stale answer lives.

The wildcard the router will refuse#

Platform gap

VyOS' forwarder rejects a wildcard name in an authoritative zone — records a * fails validation. The record editor flags a name containing * for that reason.

If you need *.lab.example.com to answer, forward that domain to a resolver that does wildcards:

set service dns forwarding domain lab.example.com name-server 10.99.0.5

and run dnsmasq as an app, where the whole thing is one line of its configuration. The catalogue entry offers exactly this as a hint on the DNS page once it is installed, with the container's real address filled in.

Check it worked#

From a client, through the router:

bash

dig @192.0.2.1 nas.example.com

And from outside, to confirm the split is where you think it is:

bash

dig @9.9.9.9 nas.example.com

Undoing it#

delete service dns forwarding authoritative-domain example.com records a nas

or the whole zone:

delete service dns forwarding authoritative-domain example.com

Clients cache. A record you delete keeps answering until its TTL expires.