In-bailiwick nameservers
A nameserver is in-bailiwick when its hostname is inside the zone it serves.
For example:
ns01.example.com.servingexample.com.is in-bailiwick.ns01.cnx.net.kh.servingexample.com.is out-of-bailiwick.
Both designs are valid. CNX's shared nameserver names are out-of-bailiwick and work normally for delegated zones.
The difference matters for two reasons: correctness and cold-query resolution cost.
Why glue records are required
Suppose example.com. is delegated to:
ns01.example.com.A resolver needs the IP address of ns01.example.com. before it can send a query to it.
Normally, the resolver would obtain that address by resolving:
ns01.example.com. A
ns01.example.com. AAAABut those records live inside example.com. itself.
That creates a circular dependency:
Where is example.com.?
→ Ask ns01.example.com.
Where is ns01.example.com.?
→ Ask example.com.The resolver cannot reach the nameserver until it knows its address, but it cannot learn the address from the child zone until it can reach the nameserver.
A glue record breaks this dependency.
The parent zone, .com, publishes the nameserver address together with the delegation. A referral can therefore contain both:
example.com. NS ns01.example.com.
ns01.example.com. A 192.0.2.53
ns01.example.com. AAAA 2001:db8::53The A and AAAA records in the parent referral are the glue.
The resolver now receives the information it needs to reach the child nameserver without first querying the child zone.
Out-of-bailiwick nameservers do not need glue
Now consider a delegation to:
ns01.cnx.net.kh.This nameserver is outside example.com., so there is no circular dependency.
The .com referral only needs to say:
example.com. NS ns01.cnx.net.kh.The resolver can independently resolve ns01.cnx.net.kh. and obtain its address.
That is perfectly valid DNS.
It does, however, mean that on a completely cold cache the resolver may need to perform a second resolution before it can contact the authoritative server for example.com..
Conceptually, the cold path becomes:
1. Resolve the delegation for example.com.
2. Resolve the address of ns01.cnx.net.kh.
3. Query ns01.cnx.net.kh. for example.com.Step 2 is a separate DNS resolution.
Depending on what is already cached, that resolution may itself require walking through the DNS hierarchy for cnx.net.kh. before the resolver learns the nameserver's A or AAAA address.
In-bailiwick glue removes that extra resolution
With an in-bailiwick nameserver:
ns01.example.com.the parent referral includes the glue address:
example.com. NS ns01.example.com.
ns01.example.com. AAAA 2001:db8::53The resolver therefore receives both the delegation and the address needed to follow it in the same referral.
The cold path becomes:
1. Resolve the delegation for example.com.
→ receive NS name and glue address
2. Query ns01.example.com. for example.com.There is no separate lookup required to discover where the authoritative nameserver itself is located.
What this does, and does not, improve
This is primarily a cold-cache optimization.
Recursive resolvers normally cache nameserver addresses, delegations, and glue. Once ns01.cnx.net.kh. is already cached, an out-of-bailiwick delegation does not require that additional resolution for every query.
In-bailiwick nameservers therefore do not make every DNS query one lookup faster.
What they do is remove one dependency from the uncached resolution path:
Out-of-bailiwick:
delegation
↓
resolve nameserver hostname
↓
query authoritative server
In-bailiwick with glue:
delegation + nameserver address
↓
query authoritative serverThis has another useful consequence: resolving the zone no longer depends on the resolver successfully completing a separate DNS resolution for an unrelated nameserver domain.
That does not automatically make an in-bailiwick design more resilient overall, but it does make the delegation path more self-contained.
See Using your own nameserver names for how to configure in-bailiwick nameservers and their glue records.