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

[Carsten Strotmann]

Hello Andreas,

"Andreas Meile" <mailingliste at andreas-meile.ch> writes:

>
> 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:

In my view, using a namespace that you own (intra.example.com, where
example.com is you domain name that you own in the Internet) is always
preferred over a non-existing TLD (such as .local, .corp or
.intra). This is also the case when using "split-DNS" with IPv4
only. 

Many problems go away when using a proper delegated DNS name, and the
Internet DNS servers (the root-dns servers) are not "polluted" by
requests for non-existing TLDs that escape improper configured internal
networks.

The non-public part of the owned namespace (intra.example.com) should be
delegated to internal DNS servers. This can be done with "split-DNS" in
a way that private IP addresses do not appear in the Internet, but are
used internally only.

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

The "not allowed" answer is the DNS "refused" return code, and that will
be send back whenever you restrict queries using "allow-query". Only if
you put IP addresses into an "blackhole"
(http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#id2564022)
(or if you block DNS queries in the firewall) the BIND DNS server will
not send any responses back and the client has to wait for a timeout.

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

I don't see this violating an RFC. Both address entries for mailmx can (and should) have a
proper PTR record (one in in-addr.arpa, and one in ip6.arpa.)

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

That is a good idea, for multiple reasons.

I don't had time to prepare examples for my suggestions here, but I
could come up with config examples if you would like to see them.

Best regards

Carsten Strotmann