Questions about delegation

[Cathy Almond]

Hi Bob(s),

All good so far.

It doesn't matter whether the authoritative servers for the delegated
subdomain are in the parent or the delegated zone.  (Actually, they
could be somewhere completely different - and if they are, it just needs
to be possible for recursive servers following the delegation to be able
resolve them - don't put their A and AAAA RRs into the parent zone).

Either way, the delegation NS records need to exist in the parent zone
(this has to happen, even if the parent is also delegating to itself).

Glue is needed to solve the 'chicken and egg' problem - so if you're
delegating a child zone to nameservers that are in the child zone
themselves, then you need glue in the parent.  (If the nameservers
you're delegating to have names in the parent zone, then you're going to
have their A and AAAA RRsets in the parent zone anyway).

----

While you're setting this up...

What also matters is that the responses from the delegated servers for
the delegated zone are consistent with the delegation.  This is
sometimes misunderstood or overlooked in GTM configurations and then
causes problems later for resolvers.  Make sure that:

1.  The GTMs are configured to respond with an SOA RR and NS RRset that
is for the zone that has been delegated to them, not the parent zone (a
commonly-seen pitfall that causes client resolution failures because
this is a lame delegation.

2.  The GTMs are configured to respond with NS RRs that are the names
that you delegated from the parent (and that those names can be
resolved) - this is just basic DNS sanity stuff, and although DNS can be
quite accommodating when it's not, it's best to get it consistent.

3.  Don't overlook that the GTMs will need to answer queries for AAAA
and any other record types - as in, they need to be authoritative for
the entire delegated zone, not just proxying the RRs that they 'know'
about.  This means responding with 'no answer no error' for a name that
exists as an A record when queried for the AAAA record instead, and
similar scenarios.  So make sure that the GTMs are fully and correctly
configured.

4.  If you've delegated across an intermediate zone (e.g. from
example.com to zone1.my.example.com) you need to make sure that queries
for anything in my.example.com are handled correctly - that is, that the
servers for example.com reply with 'no answer no error'.

Why?  Because my.example.com implicitly exists as a name, but is empty -
has no RRs and responding NXDOMAIN will cause problems for
zone1.my.example.com.

(This scenario is typically encountered by validating resolvers querying
for DS RRsets which live in the parent zone; they are queried-for by
validators, even if the responses they're validating aren't signed.
This is to check that the parent doesn't 'say' that the child zone
should be signed, in which case receiving unsigned query responses from
the child zone's servers is a DNSSEC-validation failure).

-----

The null forwarders you wouldn't ordinarily need, unless the parent zone
server is a mixed-mode resolver/auth server with global forwarding from
which you've delegated the subdomain.  In that case, if you don't want
your recursive client queries to follow the global forwarding when you
resolve them, but to use the delegation instead, then you need null
forwarders set-up.

Info here: https://kb.isc.org/docs/aa-00538

Cathy