ungleich-staticcms/content/u/blog/ipv6-vpn-dns-entries/contents.lr

title: IPv6, VPN and DNS entries
---
pub_date: 2021-10-13
---
author: Nico Schottelius
---
twitter_handle: NicoSchottelius
---
_hidden: no
---
_discoverable: yes
---
abstract:
Looking at how the patterns of VPN and DNS names changes with IPv6
---
body:

## TL; DR

With IPv6, DNS management of protected networks can be
simplified. IPv6 VPNs can use simplified DNS configurations to
simplify the network configurations by just using public, restricted
DNS entries.

## VPN and DNS in the IPv4 world

VPNs in the IPv4 world are often used to create site-to-site tunnels,
allowing different networks to talk to each other. A typical case is
that organisation A needs to access protected resources of
organisation B and maybe even vice-versa. So a typical VPN looks like
this:

```
Organisation A
--------------

Protected Host A ---------- Router/VPN gateway
(10.0.0.42/24)                      |
                                    |
                                    |
Organisation B                  (Internet)
--------------                      |
                                    |
                                    |
Protected Host B ---------- Router/VPN gateway
(10.20.0.42/24)
Host name: lakeside.int.org-b.example.com
```

Now if the Protected Host A and Protected Host B want to communicate
with each other on IP basis, this is no problem (I am not elaborating
on the problems of IP collisions in this article, a follow up article
will follow soon).

However if Protected Host A wants to reach the Protected Host B via
its internal DNS name **lakeside.int.org-b.example.com**, this is
usually a problem, for multiple reasons:

* Protected Host A might not know the right internal DNS server to
  query for int.org-b.example.com.
* Protected Host A might know the right internal DNS server to
  query for int.org-b.example.com, but might not have access to it via
  the VPN
* The DNS records for int.org-b.example.com often are intentionally
  not published to public DNS for multiple reasons: privacy related or
  because administrators don't like to publish RFC1918 records into
  public DNS records


## VPN and DNS in the IPv6 world

There are multiple ways of how VPNs can be built in the IPv6 world,
including usage of the private IPv4 addresses equivalent named Unique
Local Address (ULA). However instead of using ULA, I will today show
an approach that is more "IPv6 native", using Global Unique Addresses
(GUA), or what is simply known as "public IPv6 address".

While you might have heard it, I will repeat nonetheless: there are
enough IPv6 addresses for every practical use case that we imagine at
the moment. This is important, because we can use **globally unique
IPv6 addresses** inside the VPN.

Isn't that a problem? Publicly reachable IPv6 addresses inside a VPN?
It would, if the addresses were **globally reachable**. In the IPv6
world nothing speaks against having **globally unique, but non-routed
IPv6 addresses**. This is actually a perfect match and much better
than we can do in the IPv4 world:

* Both organisations A and B can acquire globally unique
  addresses. Let's say they organisation A acquires 2001:db8:0::/48 and
  organisation B acquires 2001:db8:1::/48.
* Both organisations have two options: they can announce their IPv6
  range to the Internet and block access to their internal network or
* both they can even consider not to announce their network at all
  (there is not route in the Internet for it)

In either case, both organisations will usually select a sub network
of size /64 for the resources they want to expose via the VPN. Let's
say organisation A chooses 2001:db8:0:cafe::/64 and organisation B
chooses 2001:db8:1:7ea::/64. Putting this in context, their VPN now
looks like this:

```
Organisation A
--------------

Protected Host A ---------- Router/VPN gateway
(2001:db8:0:cafe::42/64)            |
                                    |
                                    |
Organisation B                  (Internet)
--------------                      |
                                    |
                                    |
Protected Host B ---------- Router/VPN gateway
(2001:db8:1:7ea::42/64)            |
Host name: lakeside.int.org-b.example.com
```

Now, how does this change the DNS server situation? Because we are
using IPv6, we have many more options:

* a) We can publish the DNS records of the domain
  int.org-b.example.com globally. While access to the network
  2001:db8:1:7ea::/64 is only possible via VPN, nothing speaks against
  having the records in a public DNS server. However, some
  administrators advocate to not publish them publicly for privacy
  reasons. That is the same logic as publishing or not publish the
  RFC1918 (10.x.y.z) addresses in the IPv4 world.
* b) We can publicly/globally delegate the domain
  int.org-b.example.com to a nameserver that is only reachable via the
  VPN.
* c) We can proceed the same as in the IPv4 world and have a
  disconnect, internal DNS server that is responsible for
  int.org-b.example.com.

Option (a) is often seen as a security risk and it can be debated
whether someone who can already guess the correct hostname and
retrieve it's IP address is really a significant higher security
thread than anybody just guessing IP addresses.

Option (c) is the typical case for IPv4 based VPNs and is causing
above illustrated issues.

Option (b) is the one that makes IPv6 VPNs much more interesting than
IPv4 based VPNs:

* The world can know that there is an internal domain
  **int.org-b.example.com** and find out which DNS servers are
  responsible for it.
* However an attacker easily guesses that internal networks exist
  anyway.

Let's have a look at sample nameserver entries in detail:

```
int.org-b.example.com. NS ns-int1.org-b.example.com.
int.org-b.example.com. NS ns-int2.org-b.example.com.
```

What does that mean? Anyone in the world can retrieve the information
that int.org-b.example.com has two DNS servers. However the DNS
servers responsible for org-b.example.com can hide the IP addresses of
ns-int1.org-b.example.com and ns-int2.org-b.example.com for everyone,
but hosts coming from organisation A. Or even if the IP addressses of
ns-int1.org-b.example.com and ns-int2.org-b.example.com are world
known, access to them can easily be prevented.

The measures for this can for instance be DNS views or firewall
entries. In practice this means for VPNs in the IPv6 world:


```
Organisation A
--------------

Protected Host A: what is the IP address of lakeside.int.org-b.example.com?
DNS Server of Organisation B: 2001:db8:1:7ea::42


Outside party
-------------
Outside Hosts: what is the IP address of lakeside.int.org-b.example.com?

a) DNS Server of Organisation B: there is no domain
   int.org-b.example.com (DNS view restriction)
b) DNS Server of Organisation B: these are the nameserver for
   int.org-b.example.com, but you cannot reach them (firewall protection)
```

## Summary

For IPv6 based VPNs you can get away without reconfiguring your source
networks for DNS servers of the destination party. The target party
always needs to ensure proper access control to internal resources, so
there is no additional overhead.

DNS, correctly used in the IPv6 VPN world, is a really smooth
operation. This is why we recommend to use
[IPv6 as a basis for VPNs](https://ipv6vpn.ch).