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 ISC-BIND 9 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.
Editing the Views
ZoneType foobar.sg (In view Internet)Master | ZoneType foobar.sg (In view Azure) Master |
With Domains x Lightspeed, you can achieve multiview or split-horizon DNS by editing the appropriate view of a zone. 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. Lightspeed also offers an ASN filter, which is extremely similar in functionality to the 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 Cloud provider like Azure or Google Cloud; or by Internet provider, like SingNet or ViewQwest and not have to worry about mapping out all of their IP addresses.
If you have other questions about DNS views, we’re here to help.