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