BIND has a facility called "views", which you to control DNS resolution based on the client IP address. One common use for this is to resolve names differently for clients on a private network, using the private IP addresses, and normal public IPs for regular users, without setting up multiple DNS servers. There are other clever uses as well.

Views basically break up the DNS configuration file for BIND into different sections, and the sections apply based on the client IP address. If a client matches multiple views, the first one encountered matches.

Let's take the example that "www.example.com" and other names need to resolve to a public IP address (we'll use 172.16.1.1 in the example), but "mail.example.com" should resolve to the private address "10.1.1.1":

; ================= FILE: db.example.com ==============
; Normal DNS header information excluded for brevity
            CNAME @
www         A     172.16.1.1
ftp         CNAME @

; ================= FILE: db-private.mail.example.com ==============
; Normal DNS header information excluded for brevity
            A     10.1.1.1

; ================= FILE: db-public.mail.example.com ==============
; Normal DNS header information excluded for brevity
            A     172.16.1.1

; ================= FILE: named.conf ==============
view "private" {
   match-clients { 10.0.0.0/8; }
   zone "example.com" { type master; file "db.example.com"; };
   zone "example.com" { type master; file "db-private.example.com"; };
};

view "public" {
   match-clients { any; }
   zone "example.com" { type master; file "db.example.com"; };
   zone "example.com" { type master; file "db-public.example.com"; };
};

So, a single zone file is set up for "example.com", and both private and public zone files are set up for "mail.example.com". Then the views pull in the "example.com" zone as well as the appropriate zone file for "mail.example.com".

Another use I can imagine would be setting up an anti-spam proxy server, perhaps an out-sourced service, which only gets published in your MX records for clients that are in certain IP blocks. For example, blocks of IPs that you've had particular problems with. I could even imagine a view with an ACL of IP addresses that's fed by some of the RBLs.

Another use that comes to mind is offering different advertisements for multiple web servers at multiple data-centers, based on the client address. If you know that certain client addresses are better served from one location than another, you could resolve to the closer web server for those clients.

In practice, I haven't used views much, but they're definitely a useful thing to know about.
(Post Reply)