0

I would like to know, if a root server could delegate different subzones of a zone to different nameservers and the rest to a default nameserver.

E.g. I have the zones "thing.", "some.thing.", "any.thing", "i.do.some.thing.", "i.do.any.thing.". How should the root zone file look like, if I want the following behaviour:

Every query to "i.do.some.thing" and "*.i.do.some.thing" go to nameserver a

Every query to "i.do.any.thing" and "*.i.do.any.thing" go to nameserver b

Remaining queries to "some.thing" and "*.some.thing" go to nameserver c

Remaining queries to "any.thing" and "*.any.thing" go to nameserver d

Remaining queries to "thing" and "*.thing" go to nameserver e

Is this possible for a root name server or can only the authorative nameserver do this?

Improve this question

2 Answers 2

Reset to default
1

No, the root zone can't delegate further down in the tree of something that has already been delegated elsewhere. At least not without violating the protocol and creating strange inconsistencies.

The authoritative server for each zone can delegate any subdomains, creating new zones that can reside elsewhere.


Example of how it works:

Root (.) zone delegates example. to ns.example.

example. zone delegates foo.example. to ns.foo.example.

foo.example. zone delegates bar.foo.example. to ns.bar.foo.example.

etc.


If, instead, you had a situation where the root zone would provide authority information for something that had already been delegated elsewhere (which it does not!), like this:

Root (.) zone delegates example. to ns.example.

Root (.) zone delegates foo.example. to ns.foo.example.

You would then end up in a situation where a resolver server with a warmed up cache looking up foo.example. may already know that example. is at ns.example. and would then start querying from that point (and possibly get an entirely different response), while a resolver server with a cold cache would start querying at the root and get the delegation information from there (a delegation that shouldn't be able to coexist with the first delegation).


The above is not something that you should expect to see but I suppose with buggy software that violates the protocol or in some kind of malicious attack such responses could theoretically happen. (DNSSEC would address some such concerns when it comes to an attack.)

Improve this answer
0

Zone delegation is the primary DNS functionality

In the root zone file you have to describe hosts and subzones.

$ORIGIN thing.               ; root domain
@    IN NS   ns.thing.       ; who is responsible for root domain
ns   IN A    11.22.33.44     ; It's me itself so I have to add the "glue record"

$ORIGIN any.thing.           ; subdomain
@    IN NS   ns.any.thing.   ; who is responsible for subdomain
ns   IN A    22.33.44.55     ; address of the ns.any.thing

$ORIGIN some.thing.          ; subdomain
@    IN NS   ns.some.thing.  ; who is responsible for subdomain
ns   IN A    33.44.55.66     ; address of the ns.some.thing

Then you can do anything you want on the subdomain's NS-servers, all requests will be proceeded by their subzones.

Improve this answer
3
  • 1
    But what would happen with a caching dns server? When it caches the nameserver for the "thing." zone, wouldn't it just ask that nameserver for the subzones "any.thing" and "some.thing" and ignore my entries?
    – user1861174
    Jul 5, 2015 at 17:44
  • @Kondybas solution is correct - it does not, however, show optional TTL's which can be specified (I guess because this is not the question). The caching nameserver will ask the authorative server for the zone information, and cache that, and it will traverse that tree - ie it will cache the NS record for each subdomain and then look it up as required assuming the TTL for that zone has expired.
    – davidgo
    Jul 5, 2015 at 18:03
  • When you have delegated subzone - it's delegated. Sure if some entities are not defined in subzone then recursive request will be forwarded to the ns.thing. Say if you define hidden.host.any.thing at the ns.thing it will be resolved exactly as you want until the same hostname will be defined at the ns.any.thing.
    – Kondybas
    Jul 5, 2015 at 18:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .