Bind9 – Resolve Based on Server’s Own IP Address Requested

binddomain-name-systemnameserver

I have a bind9 DNS server with two (2) IP addresses assigned on it. Let's call them IP#1 and IP#2. I need a way to know which IP address the clients are using and respond with different results in their nslookup. I will try to explain with two examples below.

User "X" does nslookup against domainname.com with NS Server IP#1. The server should return a specific address.

User "Y" does the same nslookup against domainname.com with NS Server IP#2. The server should return a different address for him.

Any guidance on where to start looking would be a great help.

Best Answer

See bind "view" features at https://ftp.isc.org/isc/bind9/cur/9.18/doc/arm/html/reference.html#view-statement-grammar

You can match a specific zone content to a specific view and you can define a view depending on the destination IP address use, that is your server IP addresses.

view view_name [ class ] {
    match-clients { address_match_list } ;
    match-destinations { address_match_list } ;
    match-recursive-only yes_or_no ;
  [ view_option ; ... ]
  [ zone_statement ; ... ]
} ;

The view statement is a powerful feature of BIND 9 that lets a name server answer a DNS query differently depending on who is asking. It is particularly useful for implementing split DNS setups without having to run multiple servers.

Each view statement defines a view of the DNS namespace that is seen by a subset of clients. A client matches a view if its source IP address matches the address_match_list of the view’s match-clients clause, and its destination IP address matches the address_match_list of the view’s match-destinations clause.

While this feature exists and is used, note that it makes troubleshooting far more complicated, besides all problems of synchronizing data between various views. So take extra caution.

Related Solutions

BIND – Overriding DNS Entries in BIND for Internal Networks

The best method is via the response policy zone in Bind 9.8.1 or newer. It allows you to override single records in arbitrary zones (and there's no need to create a whole subdomain for that, only the single record you want to change), it allows you to override CNAMEs, etc. Other solutions such as Unbound cannot override CNAMEs.

https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html

EDIT: Let's do this properly then. I will document what I've done based on the tutorial linked above.

My OS is Raspbian 4.4 for Raspberry Pi, but the technique should work without any changes on Debian and Ubuntu, or with minimal changes on other platforms.

Go to where your Bind config files are kept on your system - here it's in /etc/bind. Create in there a file called db.rpz with the following contents:

$TTL 60
@            IN    SOA  localhost. root.localhost.  (
                          2015112501   ; serial
                          1h           ; refresh
                          30m          ; retry
                          1w           ; expiry
                          30m)         ; minimum
                   IN     NS    localhost.

localhost       A   127.0.0.1

www.some-website.com    A        127.0.0.1

www.other-website.com   CNAME    fake-hostname.com.

What does it do?

it overrides the IP address for www.some-website.com with the fake address 127.0.0.1, effectively sending all traffic for that site to the loopback address
it sends traffic for www.other-website.com to another site called fake-hostname.com

Anything that could go in a Bind zone file you can use here.

To activate these changes there are a few more steps:

Edit named.conf.local and add this section:

zone "rpz" {
  type master;
  file "/etc/bind/db.rpz";
};

The tutorial linked above tells you to add more stuff to zone "rpz" { } but that's not necessary in simple setups - what I've shown here is the minimum to make it work on your local resolver.

Edit named.conf.options and somewhere in the options { } section add the response-policy option:

options {
  // bunch
  // of
  // stuff
  // please
  // ignore

  response-policy { zone "rpz"; };
}

Now restart Bind:

service bind9 restart

That's it. The nameserver should begin overriding those records now.

If you need to make changes, just edit db.rpz, then restart Bind again.

Bonus: if you want to log DNS queries to syslog, so you can keep an eye on the proceedings, edit named.conf.local and make sure there's a logging section that includes these statements:

logging {
    // stuff
    // already
    // there

    channel my_syslog {
        syslog daemon;
        severity info;
    };
    category queries { my_syslog; };
};

Restart Bind again and that's it.

Test it on the machine running Bind:

dig @127.0.0.1 www.other-website.com. any

If you run dig on a different machine just use @the-ip-address-of-Bind-server instead of @127.0.0.1

I've used this technique with great success to override the CNAME for a website I was working on, sending it to a new AWS load balancer that I was just testing. A Raspberry Pi was used to run Bind, and the RPi was also configured to function as a WiFi router - so by connecting devices to the SSID running on the RPi I would get the DNS overrides I needed for testing.

Linux – cannot resolve DNS server’s own domain name

Rather than telling us you didn't get an Answer Section, we would be able to diagnose better if you told us what you did get, as well as the response code.

This would tell us for example whether your server is correctly serving the SOA, or if you're getting some particular error message.

FWIW, the warnings about using an alias (i.e. a CNAME) as the target of an MX or NS records are correct - you shouldn't do that.

I don't see any real config error here, but there are a couple optimisations you can make so that you don't need the real domain name anywhere in the config file:

@       IN SOA    ns1 names ( ... )        
        IN MX 10  mail

Also, the www record should also be an A rather than a CNAME - it's not really a good idea to make www an alias for the $ORIGIN, because than a query for www IN MX? or www IN NS? would return the exact same records as the domain itself, when all you ever really want is the IP address.

You also have two effectively identical records for the main A record listed. That shouldn't break anything, and maybe it's just a copy&paste error?

EDIT Curious that the duplicate A record entry was the problem - possibly the lack of IN qualifier caused a parse failure - your BIND startup logs would tell you that.

Regarding the additional questions - those would be better in a new question, and ideally quoting the actual domain name. We simply can't do effective diagnosis on live DNS issues if you're using dummy data.

EDIT2 I did fix the SOA issue though - the first entry in the SOA is supposed to be the name of the primary name server. See revised example above.

Best Answer

Related Solutions

BIND – Overriding DNS Entries in BIND for Internal Networks

Linux – cannot resolve DNS server’s own domain name

Related Topic