In message <[email protected]>, "Carsten Strotmann (private)"
writes:
> 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)?
There is no way to automatically detect this. Note
default-local-zones specifically excludes names tlds.
Having a local copy of the root zone is a much better
way to deal with queries to the root.
Mark
> Best regards
>
> Carsten Strotmann
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
