Absolutely. I generally delegate to internal NS from the public zone, and be done with it. This takes care of most use cases without all sorts of split-brain nonsense. It "just works" any time the client has permission to reach the listed resources- from colos, vpns, partners, peered vpcs, whatever. Of course this assumes prudent restrictions on connectivity.
I wasn't endorsing verio's implementation, just their use of a subdomain. Matt > On Jun 24, 2014, at 1:58 PM, Doug Barton <[email protected]> wrote: > > Yes, that's very poorly done. The proper way to do that would have been to > make the zone authoritative on their internal resolvers, and skipped the > delegation records in the parent altogether. > > Doug > > >> On 06/24/2014 01:38 PM, Jared Mauch wrote: >> >>> On Jun 24, 2014, at 4:29 PM, Matthew Ghali <[email protected]> wrote: >>> >>> Hi PHB- I'm curious when this scheme would be simpler to implement or less >>> expensive to operate as opposed to using a delegated internal subdomain of >>> an existing parent domain registration (see corp.verio.net modulo the >>> psychopathic NS rrset). I'm certainly no authority but everyone seems to >>> have a much more complicated solution to what I've always found to be a >>> simple problem. Is it the old "never expose 1918 addresses in public DNS" >>> fetish, or the related "must not expose secret internal names via DNS" >>> paranoia? >> >> It's possible to have an 'internally' visible zone, but the 'corp.verio.net' >> example I provided is somewhat like the worst of both worlds. You detail a >> lot about your zone and internal server IPs without any security benefit at >> all. >> >> One should (ideally) not respond with ULA or 1918 addresses in your AAAA or >> A responses as the behavior can be undefined. >> >> What you don't want is to be delegating everything so far that you may have >> a host querying for an internal resource sending everyone talking to their >> own local 10.x DNS server because of the way you established NS records. >> >> Your VPN and internal resolvers can be an authority on "corp.example.com" >> without exposing that to the broader internet. >> >> - jared >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
