Splitting private IP and Public IP
Mark_Andrews at isc.org
Wed Jun 18 00:47:39 UTC 2008
> On Tue, Jun 17, 2008 at 11:51:11AM -0700, Chris Buxton wrote:
> > Hold on there... You can't just suggest views without conveying the
> > full complexity of this feature.
> > What you can do, Jonah, is create a split namespace - two copies of
> > the zone, hosted on separate servers or in separate views on the same
> > server. Unless you resort to a rather complex and strange
> > configuration (involving forwarding between views, but there's more to
> > it than that), you cannot avoid duplicating the external data in the
> > internal version of the zone.
> > The BIND 9 views feature is sort of like virtual hosting in web
> > servers - multiple configurations, side-by-side on the same server,
> > that don't really have much to do with each other. In the case of
> > views, this is commonly used to create overlapping public and private
> > namespaces. Regardless of the particular use, each view is essentially
> > a separate named.conf, inside your actual named.conf; there are a few
> > things shared between views, such as the global logging statement, but
> > otherwise each view is a distinct name server configuration.
> > Chris Buxton
> > Professional Services
> > Men & Mice
> Thanks Chris and everyone else who had sent their emails privately.
> Yes, I've used views on two zones, one private and one public, and present th
> em differently. But I couldn't make it work for private IPs mixed with public
> IPs in the same zone file, and present it differently.
Which becomes extremely difficult once you start to use DNSSEC
as you then have to generate internal and external RRSIGs on the
different RRsets. You also should only send the appropriate RRSIGs
other wise validators have to do 50% more work (1/2 the time they
would choose the wrong RRSIG first).
> Trying to be "efficie
> nt", I am hoping that there are some options in views (or perhaps other "comm
> and") that I don't have to split them up to two diferent files, i.e. bind wil
> l see that the requested IP is private (defined by the admin), don't show it
> to public.
> I'm not sure if views will work in our current infrastucture. For the sake of
> discussion, I've one internal master and one external/public slave. Everyone
> is using the slave to resolve host's IP, be it internal or public IP. Using
> views, how will the slave get a zone that contains, internal or public IP fro
> m the master? Any hint?
You would use exactly the same criteria for stripping the
RFC 1918 address or not as you would to select which view
to answer from.
Alternatively you could move to IPv6 and forget all about
RFC 1918 internally. Things are much simpler when you don't
have to play games with ambigious addresses. You will still
have to do address translation to talk to the IPv4 world but
you were doing that already.
IPv4 should have died years ago. It's only hacks like NAT
that have keep it going so long.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the bind-users