You can certainly configure the subdomains that way, but the same resolver
which followed the subdomain.example.com delegation in the first place, to your
BIND instance, will presumably follow the delegation of
sub.subdomain.example.com (as it is published via NS records in the parent
zone) to find the nameservers for that subzone, query them, and expect
authoritative responses. Your forwarding config won't be used, by such a
resolver, since it'll be sending you non-recursive (RD=0) queries, which are
incompatible with forwarding.
Ultimately, the bottom line is that if the "leaf-node" data is not available in
an authoritative form, then you can't use delegation alone to facilitate its
resolution. You'd need to set up some sort of forwarding, possibly multi-hop
forwarding, which is notorious for being fragile, inefficient and lacking in
scalability.
You mentioned in another post that the DNS data in question is for a cloud
environment. My experience so far (primarily with AWS) is that these cloud
providers don't understand how robust DNS enterprise architectures work. If
they did, they would have offered authoritative, replicate-able DNS zone data
as a basic service, straight out of the gate. Supposedly this "feature" is "on
the roadmap" for AWS, but it seems to be a distant goal, with no particular
priority. In the meantime, they are requiring their enterprise customers to
sacrifice some of the reliability and performance we've built up in our DNS
infrastructures over years (and, in some cases, decades), instead stringing
together forwarding hierarchies and other nonsense like that.
(Editorial note: I originally got carried away at this point, explaining my
model of how DNS is, conceptually, constructed -- authoritative core, inner
iterative-resolution layer, outer recursive-resolution layer -- along with a
diatribe about how poor/junior enterprise DNS architects try, with sub-optimal
results, to build on recursive resolution as a foundation, because that's the
only layer they really understand. But I don't want to put anyone to sleep, or
fill up their mailboxes with walls of text, so I'll forego that for now, saving
the text for some other day).
May I ask: why would you put anything non-AD-related, of actual importance, in
a *subdomain* of an Active Directory zone ? Maybe it's just a matter of
perspective, but I see Active Directory as just one service we run in our
enterprise, among many. So, while it gets its own namespace, it doesn't get to
control the *main* namespace -- certainly, we would never put anything
non-AD-related *underneath* an AD zone. Granted, I don't know your
organization's structure, internal politics, history, etc. But it just seems
rather odd to me that you're delegating stuff from an AD zone. I view such
namespaces as "leaves", not "branches".
- Kevin
-----Original Message-----
From: bind-users [mailto:[email protected]] On Behalf Of
seanliam73
Sent: Wednesday, October 11, 2017 3:45 AM
To: [email protected]
Subject: RE: Forwarding from delegated zone not working
Thanks Kevin
That is what I suspected. If I make the delegated server the master/slave for
the sub-domain that has been delegated, could I then set up forward zones for
further sub-domains? i.e
subdomain.example.com (delegated domain set as master zone)
sub.subdomain.example.com (forward zone)
Sean
--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
