[Architecture discussion] IPv6 and best practices for DNS naming and the MX/SMTP problem

Sun May 26 18:36:39 UTC 2013

Hello BIND users

The following post discusses some complexer questions in context with
enabling dual-stack in corporate networks. It's very TCP/IP generic but has 
also a lot to do with DNS (and of course BIND which I use to implement it => 
all examples are in BIND syntax) so I hope it's not too offtopic.

Introduction: In the Internet's origins it was intended that any device uses
a public IPv4 address and has a FQGH (full qualified hostname) inside the
worldwide public DNS hierarchy.

With the predictable IPv4 address depletion, NAT and private networks using
IPv4 addresses according RFC 1918 are common which resulted in a new
problem: The FQHN for my corporate server or workstation cannot longer
inserted into the public DNS hirarchy so separate internal DNS
infrastructures based on TLD .local/.loc got common in many larger network
installations (the famous split DNS scenarios).

Today after the IPv4 address exhaustion has become reality, enabling
dual-stack on existing networks, i.e. adding IPv6 will become a topic to
virtually every Internet user. Because IPv6 offers more than enough IPv6
addresses to really everyone, networking with a working end-to-end
communication with public IP address for every device as in the Internet's
first ages gets back.

Let's assume a simple network situation: segmented network inside a company
with a small routed public IPv4 range (a /29 subnet for example) and an
internal network behind a firewall. Pure IPv4 past situation first:

Public webserver (Linux running Apache and BIND for example):
webserv.example.com  192.0.2.21

Firewall:
Internal: vpn.example.local 10.0.0.1
External: vpn.example.com 192.0.2.30

File server (running as Microsoft ActiveDirectory for example but could be 
also a Linux box running Samba and BIND):
fileserv.example.local   10.0.0.12

Everything extended to dual-stack:
webserv.example.com  192.0.2.21 + 2001:db8:0:1::21

Firewall:
Internal: vpn.example.local 10.0.0.1 + 2001:db8:0:2::1
External: vpn.example.com 192.0.2.30 + 2001:db8:0:1::30
(doing NAT for IPv4 but routing IPv6)

fileserv.example.local   10.0.0.12 + 2001:db8:0:2::12

First question for discussion: Is it recommended to replace "example.local"
into "intra.example.com" for example because it's now possible to restore
the public DNS hierarchy? See the following:

$ORIGIN example.com.
intra    IN  NS    fileserv.intra.example.com.
; Glue record
fileserver.intra  IN  AAAA  2001:db8:0:2::12
; fileserver.intra  IN  A 10.0.0.12 would violate some RFCs because of
; publishing non-routed IPv4 addresses but omit it breaks the worldwide
; hierarchy, i.e. intra.example.com from IPv4 sight is "flying free" 
somewhere...

; assume a /56 from ISP and delegated from ISP
$ORIGIN 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1.0    IN   NS  webserv.example.com.
2.0    IN   NS  fileserv.intra.example.com.
$ORIGIN 1.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN  PTR  webserv.example.com.
0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN  PTR  vpn.example.com.

; managed by ActiveDirectory (or BIND, too)
$ORIGIN 2.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN  PTR  vpn.intra.example.com.
2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0  IN  PTR  fileserv.intra.example.com.

Because of confidence reasons: Is it wise the setup a query restriction for
intra.example.com as well as 2.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa to
allow dns querys for trusted networks only? Is there a "not allowed" answer
in DNS standard to avoid waiting until timeout for an external host doing
gethostbyaddr()? (the firewall might disallow DNS from extern to
fileserv.intra.example.com so blocking may be problematic)

Another problem: e-mails/SMTP and MTA. Assume a mail server inside the
corporate network (or even a DMZ behind a NAT!)

Early before dual-stacking:
mailserv.example.local  10.0.0.14
Now after dual-stacking:
mailserv.intra.example.com  10.0.0.14 + 2001:db8:0:2::14

In the past, something like

define(`confDOMAIN_NAME', `vpn.example.com')dnl

(Sendmail) was common to get a matching visible host name to outside MTAs
and spam filters (beware of the IPv4 NAT) and for incoming mail

$ORIGIN example.com.
@    IN    MX    10    vpn.example.com.

was very common. With the removal of NAT in IPv6, we don't longer need an
overwritten MTA's domain name, instead we can use

$ORIGIN example.com.
@    IN    MX    10    mailserv.intra.example.com.

directly in that case. But this causes the next problem: not dual-stack
compliant (IPv4 MTA gets an non-routed IP address). A workaround may be
announce both hosts:

$ORIGIN example.com.
; for IPv4
@    IN    MX    10    vpn.example.com.
; for IPv6
@    IN    MX    10    mailserv.intra.example.com.

but this may cause timeouts (IPv6 host is trying to connect to the firewall
instead the mail server). Another way might be

$ORIGIN example.com.
@    IN    MX    10    mailmx.example.com.
mailmx  IN   A     192.0.2.30
mailmx  IN   AAAA  2001:db8:0:2::14

but this violates the RFCs saying that A/AAAA entries should have a
corresponding PTR entry.

A third way might be to use smart relay hosts so the actual outgoing mail
server always runs with public IPv4 address, the same for the incoming way.

A living discussion about this topic is also welcome because I believe that
many network engineers must deal with such questions in the next time! 
Reports/Success stories from such migration projects are also welcome.

Thanks in advance for giving good links to RFCs and primers/articles in
general about this complex topic. :-)

        Andreas
-- 
meile.biz IT solutions, Hauptstrasse 63, CH-8242 Hofen SH
PC/Netzwerk-Support, Web-Entwicklung und -Hosting, IT Security
Tel. +41 52 640 04 72 * Fax +41 52 640 04 73 * Mobile +41 79 334 05 67
Postfach 169, CH-8240 Thayngen * info at meile.biz * http://www.meile.biz 