Subject: [DNSOP] Question about detecting generated local-zones (relates todraft-ietf-dnsop-default-local-zones-08)

From: "Carsten Strotmann (private)" <[email-masked]>
Date: Tue, 28 Jul 2009 10:51:00 +0200

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Jul 2009 13:59:08 +1000

> 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-masked]
> 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-masked]

---

From: "Carsten Strotmann (private)" <[email-masked]>
Date: Wed, 29 Jul 2009 10:50:58 +0200

> 	way to deal with queries to the root.

This would be a good solution for DNS literate administrators, however I 
mostly deal with people that are part-time DNS admins and having them 
manage an internal root zone would probably do more harm than good.

However I found that there is a way to detect these kind of zones, that 
is to check for the SOA RNAME "nobody.invalid", as this is already 
defined in the draft (sometimes it is hard to see the obvious) and can 
work in the same way as an defined SOA serial.

Carsten