Best way to handle a delegation...

Grant Taylor gtaylor at tnetconsulting.net
Sun Jan 22 02:59:37 UTC 2017


On 01/20/2017 05:24 PM, Ray Van Dolson wrote:
> So I have domain.com, controlled by AD, but want to delegate
> subdomain.domain.com to an external DNS server on the Internet (Amazon
> Route53).

Okay...

> This is easy to do for my external version of domain.com as I can just
> add
>
> subdomain.domain.com        NS      amazonserver.com.

*nod*

> However, our AD servers aren't allowed to talk to the Internet, so it's
> not quite so straightforward.

Does "AD servers" mean Domain Controllers?  Or anything talking to / 
joined to AD?

> I haven't tried 4 as it's basically a more complex version of 3, but 3
> doesn't work for some reason.  The caching server has access to the
> Internet, but when I point dig at it and ask for
> record.subdomain.domain.com, I just get the SOA record back rather than
> full recursion via the delegation via the defined NS servers.  I
> suspect the fact that subdomain.domain.com is defined as a master zone,
> I can't really delegate the whole thing elsewhere...

It sounds to me like internal systems (non-DCs) do have a method to 
resolve external domains, even if it's via one or more DNS servers.  Is 
this correct?  (I'm going to assume yes.)

> Is there a cleaner way to approach this (short of renaming our
> domain!)?  Maybe forwarding is the best approach.

Please forgive the naive question, but why can't you just delegate from 
domain.com to subdomain.domain.com, even internally?  As long as you 
have the necessary NS records, I don't see any reason why your internal 
clients can't use the same mechanism for subdomain.domain.com that they 
already use for lists.isc.org.

Maybe I'm missing something or maybe there's something else in your 
infrastructure that precludes simple delegation.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170121/cb3cea8f/attachment.bin>


More information about the bind-users mailing list