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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
