Hello
I need opinions from the DNS community on an issue with default-local zones.
This was triggered by hosting an empty 'local' unicast zone to stop
unwanted local traffic to leak from local networks.
Avahi (multicast DNS and Autoconf for Linux/Unix) recommends to check
for the existence of an unicast "local." DNS Domain on startup and
disable Avahi when such an domain has been found (
http://avahi.org/wiki/AvahiAndUnicastDotLocal ).
Ubuntu 9.04 implements this recommendation by querying for an SOA record
for "local." in the startscript and it disables Avahi when the query
returns an NOERROR answer. This is implemented so that Avahi (which used
the 'local' pseudo-TLD for mDNS) does not collide with an unicast Domain
of the same name that is used for real DNS resolution (this is often
found in Microsoft Windows AD deployments, as 'local' is used in some
documentation as an example and is copied by the administrators).
This scheme conflict however in a situation where the DNS admin has
configured zones for DNS namespace that should be kept local (that is,
should not reach out into the internet and reach the Internet Root) such
as 'local.', 'belkin.', 'onion.' on the perimeter resolving DNS servers.
I'm now searching for a good way to distinguish a pseudo TLD configured
to block local traffic from a real unicast TLD used internally, so that
Avahi (and maybe other mDNS implementations) can make a better decision.
I am aware of the problem of mDNS using the 'local.' pseudo-TLD, that
should not be the topic of this discussion.
draft-ietf-dnsop-default-local-zones-08 gives an example of an SOA
record with serial number "1", however it does not specifies the serial
number used. It only requires that the "empty zones one SHOULD NOT use
the same NS and SOA records as used on the public Internet servers as
that will make it harder to detect the origin of the responses and thus
any leakage to the public Internet servers."
The BIND DNS Server implements "default-local-zones" with an serial
number of "0" in the SOA record. Unbound implements the same with an
serial number of "1". I need to test how the Microsoft DNS Server is
handling this.
One possible solution for detecting an "default-local-zone" created to
stop local traffic at the perimeter is to define a standard SOA serial
of "0", so that Avahi and other mDNS implementations can check against
this serial. A unicast zone with real DNS content will most of the time
have a SOA serial != 0, whereas a "default-local-zone" will always have
a SOA serial of "0".
My questions:
Is it in general seen as a good practice to configure empty zones for
namespaces not used in the Internet which might appear in an local
(enterprise/university/ISP) network like "local." and "belkin." on
perimeter resolving DNS server to stop this names to leak out into the
Internet?
Would it make sense to define a SOA serial of "0" (or "1", but I would
prefer zero) in draft-ietf-dnsop-default-local-zones for this kind of zones?
Are there possible other ways of detecting "default-local-zones" (other
than looking at the serial)?
Best regards
Carsten Strotmann
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
