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

Kevin Darcy kcd at chrysler.com
Tue May 28 17:29:02 UTC 2013

On 5/26/2013 2:36 PM, Andreas Meile wrote:
> 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
> Firewall:
> Internal: vpn.example.local
> External: vpn.example.com
> File server (running as Microsoft ActiveDirectory for example but 
> could be also a Linux box running Samba and BIND):
> fileserv.example.local
> Everything extended to dual-stack:
> webserv.example.com + 2001:db8:0:1::21
> Firewall:
> Internal: vpn.example.local + 2001:db8:0:2::1
> External: vpn.example.com + 2001:db8:0:1::30
> (doing NAT for IPv4 but routing IPv6)
> fileserv.example.local + 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 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
> 1.0    IN   NS  webserv.example.com.
> 2.0    IN   NS  fileserv.intra.example.com.
>  IN  PTR  webserv.example.com.
>  IN  PTR  vpn.example.com.
> ; managed by ActiveDirectory (or BIND, too)
>  IN  PTR  vpn.intra.example.com.
>  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 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
> Now after dual-stacking:
> mailserv.intra.example.com + 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). 

I don't see what the problem is here: if the IPv4-only MTA is really old 
and crude, it'll just discard the AAAA records in the DNS response, 
because it doesn't understand them at all. If it's more modern, then 
it'll presumably implement RFC 6724 (address selection RFC, perhaps some 
might recognize this as RFC 3484bis), in which case the algorithm 
dictates that it'll connect to the IPv4 address and *only* the IPv4 
address. Which is exactly what you want.

> 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). 

Any time you publish an MX record that is unreachable from some of the 
clients that will try to look it up and use it, whether it's because of 
IPv4-versus-IPv6 issues, routing issues, firewall rules, etc., you risk 
timeouts. Best to try and avoid this.

> Another way might be
> $ORIGIN example.com.
> @    IN    MX    10    mailmx.example.com.
> mailmx  IN   A
> mailmx  IN   AAAA  2001:db8:0:2::14
> but this violates the RFCs saying that A/AAAA entries should have a
> corresponding PTR entry.
Doesn't violate it at all. The IPv6 reverse entry points back to 
mailmx.example.com and the IPv4 reverse entry, with a *different* owner 
name, also points back to mailmx.example.com. There's nothing that says 
a given name in the DNS can only be pointed to by one and only one 
reverse record. If that were the case, round-robins would *always* break 
one best-practice rule or another.
> 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.
But now you're complicating your SMTP routing architecture to 
accommodate (what you perceive to be) a client behavior problem. I 
believe RFC 6724 already takes care of the problem -- or it's not a 
problem at all, because really dumb IPv4-only clients just ignore AAAA 
records -- so all of these other contortions are unnecessary.

                             - Kevin

More information about the bind-users mailing list