Imagine a very common scenario where you have a firewall, and behind that firewall you have a few servers, one of them named api.example.com. This is most commonly configured with the firewall exposing a public IP address to the Internet, e.g., 1.2.3.4, which connects back to the API server at its internal IP address, e.g., 192.168.3.4.
If you’re outside the firewall and try to connect to the API server, then you need DNS to resolve api.example.com to 1.2.3.4. But what if you’re also behind the firewall? This might be the case if you’re a web server, and need to make API calls on behalf of web visitors. If you try to connect to 1.2.3.4, then you have a problem: your packet is going to go out the firewall and then attempt what is known as a “hairpin turn” to come back in – and this just doesn’t work.
To solve this, the DNS introduced the concept of “views” – different sets of answers for the same record depending upon the source of the resolution request. In other words, you can configure your DNS service such that if someone outside the firewall asks, “what is the IP address for api.example.com?” you answer, “1.2.3.4”. But if someone inside the firewall asks the same question, you answer, “192.168.3.4”. This avoids the whole hairpin turn problem.
The challenge with DNS views as implemented in ISC BIND is that you must duplicate the entire domain – the entire zone file – and then serve one copy to one view, and a second copy to a different view, even if you only want a different answer on a single record. Trying to maintain two copies of the same zone with slight differences between them can quickly turn into a real mess.
With NS1, you can achieve multiview or split-horizon DNS by adding the NETFENCE_PREFIX filter to a record, and then associating the IP subnet(s) to which you want a particular answer served as metadata on that answer. In other words, you create a view for one or more specific IP address ranges, and then associate that view with one or more answers within a single record. No duplicating the whole zone, and no worrying about trying to keep all of your single-view records in synchronicity.
This can be extremely useful in all manner of scenarios, including the example we talked about earlier, but also in offices, with peering arrangements between providers, connections between data centers, and much more. NS1 also offers the NETFENCE_ASN filter, which is extremely similar in functionality to the NETFENCE_PREFIX filter, but instead of operating on IP address ranges, it operates upon the Autonomous System Number (ASN) of the source of the resolution request. This allows you to easily create a DNS view that is tied to an entire Internet provider, like Sprint or Level(3) and not have to worry about mapping out all of their IP addresses.
If you have other questions about split-horizon DNS we’re here to help.