Hello Andreas, "Andreas Meile" <mailingli...@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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users