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

Carsten Strotmann cas at strotmann.de
Mon May 27 06:20:36 UTC 2013

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

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

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

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

More information about the bind-users mailing list