Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.protocols.dns.bind > #15736 > unrolled thread

Re: What is the proper way to delegate to a private / hidden sub-domain?

Started byGrant Taylor <gtaylor@tnetconsulting.net>
First post2020-05-06 16:04 -0600
Last post2020-05-06 16:04 -0600
Articles 1 — 1 participant

Back to article view | Back to comp.protocols.dns.bind

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: What is the proper way to delegate to a private / hidden sub-domain? Grant Taylor <gtaylor@tnetconsulting.net> - 2020-05-06 16:04 -0600

#15736 — Re: What is the proper way to delegate to a private / hidden sub-domain?

FromGrant Taylor <gtaylor@tnetconsulting.net>
Date2020-05-06 16:04 -0600
SubjectRe: What is the proper way to delegate to a private / hidden sub-domain?
Message-ID<mailman.370.1588802665.942.bind-users@lists.isc.org>

[Multipart message — attachments visible in raw view] — view raw

On 5/6/20 3:38 PM, John Levine wrote:
> The DNS server sends different answers depending on the client IP,
> so on your internal network it sees the private subdomain,
> everywhere else sees a ENT or NXDOMAIN.

Thank you for confirming.  That is indeed what I /thought/ we were 
talking about.  But given the difference in what you were describing and 
what I was thinking, I figured that it was worth confirming.

> If you really have to use physically separate servers for reasons 
> that you can't explain,...

There's not anything stopping me from explaining.

The main network I want dig +trace to behave (as) correctly (as 
possible) is inside the labs.  (Obviously tracing won't work without 
some support infrastructure on the disconnected labs.)

The external server is more to make the delegation into the labs look as 
clean as possible to the rest of the world.  I.e. return NXDOMAIN 
instead of timeouts.

In some ways, the external aspect is somewhat optional, save for the 
desire to lay nice with others.

I'd like to consistently re-use the same method across all labs, 
independent if they are isolated or not, both internally and externally.

> ...I suppose putting the two servers at the same IP addresss facing 
> different networks could work,

Hence "anycast".

> although you're asking for trouble with route leaks anytime someone 
> adjusts a router anywhere near one or the other.

In general, I agree with you.  However, in this particular case, I don't 
think it's going to be an issue.  The router inside the lab is not using 
any routing protocols, only static configs.  The router can get the 
local traffic to the anycast IP without worrying about anything 
escaping.  (Be it on the router w/ local DNS server, or directly 
attached network, or a host route to another system that is directly 
attached.)

I'm taking your warning, processing it, and then deciding that this 
particular scenario is not subject to the concerns you rightfully have.

> Remember that with normal anycast all of the mirrors send identical 
> or at least equivalent answers so the routes are not a security 
> issue.
Agreed.



-- 
Grant. . . .
unix || die

[toc] | [standalone]


Back to top | Article view | comp.protocols.dns.bind


csiph-web