Subject: Re: [dnsop] WGLC: draft-ietf-dnsop-default-local-zones-00.txt

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 6 Sep 2006 15:55:22 +0200

On 8Aug 2006, at 3:05 PM, Peter Koch wrote:

> Dear WG,
>
> this initiates a Working Group Last Call for
>
> 	draft-ietf-dnsop-default-local-zones-00.txt
>
> to end Thursday, 2006-08-24 23:59:59 UTC
>

The last call appeared during my vacation, apologies for the later  
reply.

Bottom line: I think this is important work and support it to  
eventually be published as BCP. But....

The text needs a bit more attention.

I had the benefit of reading the thread so I was not so surprised  
that I had to read section 3 a couple of times and still didn't get  
it. So, I think that the suggestions by Peter are actually needed to  
improve readability and to make this document useful for the regular  
admin. I am not sure if that is sufficient.

Wouldn't it be a sensible suggestion to enter the e-mail address of  
the 'local' adminsitrator for the MMAIL field?

As for Ed's question:
> Chapter 4 needs FQDN's in it.  Also, why the IANA registry  
> reference? I don't see that IANA needs to have a list of these  
> "should be split-view'ed" zones.

This is because you want to be able to point to a central place where  
the list of names is maintained for which queries SHOULD NOT get out  
on the internet. Besides you want to carefully control what gets on  
that list. Hence an IANA registry, including the highest possible  
review bar to get data in that registry. Or am I not listening  
carefully and missing Ed's point?

Just a question. How is this going to be 'evenginerized'. Just  
creating a BCP is not sufficient. This is something that can be part  
of example configs in nameserver code but then the question is how to  
turn it on and get the appropriate parameters. In other words who is  
going to do the marketing after the IETF is done with it?

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: [email-masked]
Date: Wed, 6 Sep 2006 16:03:46 +0000

> going to do the marketing after the IETF is done with it?

	hum... well, ISC has already coded this up in the current
	BIND distributions, so for folks updating their code base,
	its turned on by default.  ...  why the IETF needs to do
	anything here to ratify an ISC action is mostly beyond me.

	anyway.  i think this is a huge mistake.
	codifying "special" behaviour is a bear to clean up when
	the "special" nature of the bahaviour changes.
	granted, such behaviour may not change in the next few years,
	but when it does change (and it will) - ripping all this cruft 
	out of deployed systems will take forever.

	i'm increasingly dubious about the institutionalization of
	one view of the "Internet".  Yeah, Ed has had the fortune to
	work for sites who have, by policy, had a walled garden approach
	to connecting to any network (regardless of transport protocol)
	and such techniques are common... but in such models break down
	in the ad-hoc and truly mobil networking theaters.

	so as a lone disenting voice in the wilderness, i think this is 
	a bad idea ... and i am a bit resentful that ISC implemented
	such features before the IETF sactioned them.  (yet another code
	patch that I must make -every- time i update BIND code from ISC)

--bill
.

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Sep 2006 12:39:27 -0400

> 	patch that I must make -every- time i update BIND code from ISC)

Just to be clear, what have ISC implemented, and in what versions of  
BIND? Is there new behaviour which is on by default which causes  
resolvers to answer the queries discussed in this draft locally?

Joe

.

---

From: bert hubert <[email-masked]>
Date: Wed, 6 Sep 2006 18:59:15 +0200

> resolvers to answer the queries discussed in this draft locally?

fwiw, the PowerDNS Recursor starting from 3.0.something does the same thing
(answer locally) but it can be disabled.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: [email-masked]
Date: Wed, 6 Sep 2006 17:04:26 +0000

> resolvers to answer the queries discussed in this draft locally?

 	ISC has implemented this in at least 9.3.2 and 9.3.2-P1:

Sep  6 04:01:09 shim named[13388]: automatic empty zone: D.F.IP6.ARPA
Sep  6 04:01:09 shim named[13388]: automatic empty zone: 8.E.F.IP6.ARPA
Sep  6 04:01:09 shim named[13388]: automatic empty zone: 9.E.F.IP6.ARPA
Sep  6 04:01:09 shim named[13388]: automatic empty zone: A.E.F.IP6.ARPA
Sep  6 04:01:09 shim named[13388]: automatic empty zone: B.E.F.IP6.ARPA
Sep  6 05:01:16 shim named[13388]: automatic empty zone: 127.IN-ADDR.ARPA
Sep  6 05:01:16 shim named[13388]: automatic empty zone: 254.169.IN-ADDR.ARPA
Sep  6 05:01:16 shim named[13388]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Sep  6 05:01:16 shim named[13388]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
Sep  6 05:01:16 shim named[13388]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Sep  6 05:01:16 shim named[13388]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA

...

	which seems just a bit preumptious ... 
	the existence of these "empty" zones does have interesting
	behaviour for resolvers that use a server where such zones
	are created.

	are these prefixes properly accounted for, with delegation
	authority by either the IANA or any of the RIRS to your knowledge?
	Does the IETF even have the authority to make address/prefix delegations?

	the answer is no, to all questions, to my understanding.
	and so I have to rip out this code from the ISC distribution.

--bill
.

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Sep 2006 13:14:37 -0400

> 	ISC has implemented this in at least 9.3.2 and 9.3.2-P1:

Huh. I thought that was a new feature in 9.4, and was off by default.  
None of the resolvers I run (all using 9.3.2) log those entries, and  
queries for (e.g.) "d.f.ip6.arpa in soa?" give me an answer which  
doesn't seem to be synthesised locally:

[lucy:/var/named/log]% dig @127.0.0.1 d.f.ip6.arpa soa

; <<>> DiG 9.3.2 <<>> @127.0.0.1 d.f.ip6.arpa soa
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56608
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;d.f.ip6.arpa.                  IN      SOA

;; AUTHORITY SECTION:
ip6.arpa.               10797   IN      SOA     dns1.icann.org.  
hostmaster.icann.org. 2006071901 3600 1800 604800 10800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep  6 17:12:08 2006
;; MSG SIZE  rcvd: 91

[lucy:/var/named/log]%
[lucy:/var/named/log]% named -v
BIND 9.3.2
[lucy:/var/named/log]%
[lucy:/var/named/log]% dig @127.0.0.1 version.bind ch txt +short
"9.3.2"
[lucy:/var/named/log]%

This thread is getting a little BIND-specific, however. Perhaps we  
shouldn't dwell on such details for much longer on this list.

Joe

.

---

From: [email-masked]
Date: Wed, 6 Sep 2006 17:21:02 +0000

> shouldn't dwell on such details for much longer on this list.

	you -did- ask.  :)
	and to bring this back home... i'm still not in favor of
	this type of behaviour, the creation of "special" things
	on a LOCAL basis.  when such things need to be eradicated,
	it willbe near impossible to clean up.
	
	this draft should be nuked and the behaviour in code should
	be crafted by each administrator, as their local policies
	dictate... IMHO

--bill
	
.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2006 08:20:01 +1000

> the 'local' adminsitrator for the MMAIL field?

	You want the default to be something that doesn't require
	any configuration.  Local overrides are fine.
 
> going to do the marketing after the IETF is done with it?

	BIND 9.4.0 already has all but for the RFC 1918 addresses
	in it.  The RFC 1918 prefixes are #ifdef out waiting for
	this to go to BCP.  Unfortunately changes to the status quo
	sometime need a BCP as this sort of change will require
	many to change their configurations.
 
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2006 08:29:42 +1000

>  	ISC has implemented this in at least 9.3.2 and 9.3.2-P1:

	ISC has NOT implemented this in 9.3.2 or 9.3.2-P1.
	
	It is in BIND 9.4.0 which is currently at rc2.  It can also
	be disabled at runtime with a single named.conf option.
 
> Sep  6 05:01:16 shim named[13388]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
> Sep  6 05:01:16 shim named[13388]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.
> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
> 
> ...
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2006 08:46:59 +1000

> 	be crafted by each administrator, as their local policies

	Local administrators clearly don't do this at the moment
	despite being required to do so for the last 10 years
	for RFC 1918 addresses.  The RFC 1918 prefixes would
	not have been delegated to sacrifical servers if local
	administrators were doing the right thing.

	Local administators can still craft the policy.  In fact
	the BCP says that if you implement this in code you have
	to have configuration hooks to turn it off.

	Named has the following hooks and I'm sure PowerDNS will
	also have similar hooks.  Named also has some additional
	heuristics which will disable individual empty zones based
	on other configuration details.  Most cases where there are
	populated reverses for RFC 1918 address they will just
	continue to work.

		empty-server <string>;
		empty-contact <string>;
		empty-zones-enable <boolean>;
		disable-empty-zone <string>;

	Mark

---

From: [email-masked]
Date: Thu, 7 Sep 2006 01:32:40 +0000

> 	despite being required to do so for the last 10 years

	really?  i've not seen that.

> 	administrators were doing the right thing.

	that is not particularly true, since i was the one
	who proposed the creation of the sacrifical servers in 
	the first place.  

.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Sep 2006 12:09:44 +1000

> 	really?  i've not seen that.

   RFC 1918

   Indirect references to such addresses should be contained within the
   enterprise. Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses. In particular, Internet service providers should take
   measures to prevent such leakage.

	This covers the reverse prefixes for these address ranges.

> 	who proposed the creation of the sacrifical servers in 

	You mean to say that it wasn't prompted by leaked reverse
	queries for these ranges?

---

From: [email-masked]
Date: Thu, 7 Sep 2006 03:43:56 +0000

> 	This covers the reverse prefixes for these address ranges.

	noting the distinction btwn "should" and "SHOULD"
	they are different in the IETF.

> 	queries for these ranges?

	nope.  but we have wandered far afield of the call for 
	support for this draft.  I don't support it.  

--bill

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 12 Sep 2006 12:04:49 +0200

> 	any configuration.  Local overrides are fine.

But isn't the default as provided by the software vendor. So why not  
something like rfcXXXX.blafoo.nl (in case blafoo would be the vendor  
of the resolver) and have a auto-responder behind that address?

I think it is a good habit to have "real" addresses in SOA MNAME  
fields. So the draft suggests the mname to contain the 'local'  
administrator (SHOULD) and the vendor puts its own default. (It is  
unfortunate that such address will become a spam magnet).

--Olaf

.

---

From: Peter Koch <[email-masked]>
Date: Tue, 12 Sep 2006 20:22:25 +0200

> of the resolver) and have a auto-responder behind that address?

My feeling is that this is beyond what we can successfully recommend in a BCP.

> unfortunate that such address will become a spam magnet).

It would also be a spam reflector and open a can of worms IMHO.
I wonder if those people clever enough to dig out the RNAME really
would need the help of an auto responder. My point about avoiding the "."
was more to say "." != "no address" (waiting for someone to point me to the
existing (bad) precedent).

-Peter
.

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Sep 2006 16:02:04 -0400

On 2006-09-12, at 14:22, Peter Koch wrote:

> My point about avoiding the "."

I've seen many people use "." as part of MX RDATA to indicate that a  
host should not receive mail (e.g. "PRINTER.EXAMPLE.COM. 3600 IN MX  
0 ."). I seem to remember that meaning is documented informally in  
Cricket Liu's book, but I could be wrong about that (I don't have a  
copy near the keyboard).

In any case, the MX RDATA meaning is not entirely dissimilar to the  
intended interpretation of "." as RNAME data, at least to my eye.

Joe
.

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Sep 2006 21:43:24 +0100

On Tue, 12 Sep 2006, Joe Abley wrote:
>
> I've seen many people use "." as part of MX RDATA to indicate that a host
> should not receive mail (e.g. "PRINTER.EXAMPLE.COM. 3600 IN MX 0 ."). I seem
> to remember that meaning is documented informally in Cricket Liu's book, but I
> could be wrong about that (I don't have a copy near the keyboard).

The "no service here" meaning of this kind of "." is explicitly specified
for SRV records. The specification for MX records is more vague, but RFC
2821 does say "If MX records are present, but none of them are usable,
this situation MUST be reported as an error."

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Kare Presttun <[email-masked]>
Date: Tue, 12 Sep 2006 22:39:14 +0200

Shouldn't the forward zones of RFC2606/BCP32 be included
in the document?

--
Best regards,
Kare Presttun
.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 12 Sep 2006 15:39:39 -0700

On Sep 12, 2006, at 1:43 PM, Tony Finch wrote:

>> I've seen many people use "." as part of MX RDATA to indicate that  
>> a host should not receive mail (e.g. "PRINTER.EXAMPLE.COM. 3600 IN  
>> MX 0 ."). I seem to remember that meaning is documented informally  
>> in Cricket Liu's book, but I could be wrong about that (I don't  
>> have a copy near the keyboard).
>
> The "no service here" meaning of this kind of "." is explicitly  
> specified for SRV records. The specification for MX records is more  
> vague, but RFC 2821 does say "If MX records are present, but none  
> of them are usable, this situation MUST be reported as an error."

Even with the "." defined in the SRV record as "no target", there are  
attempts to resolve "." hostnames.  Using this "." syntax where a  
local-part.hostname is expected, how often will "." be resolved?  The  
desire of this draft is to prevent extraneous.  Could "localhost." be  
used instead?  Still no valid email-address can be generated, where  
resolving localhost might not set a bad precedence.

-Doug

.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Sep 2006 09:23:11 +1000

> existing (bad) precedent).

	RP.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 13 Sep 2006 09:43:42 +0200

> My feeling is that this is beyond what we can successfully  

The BCP would reccomend the e-mail address of the local  
administrator. The software vendor still needs to pick a sensible  
default. I was trying to cook up something for the latter.

> It would also be a spam reflector and open a can of worms IMHO.

Agreed, on the other hand the vendor could also send all mails  
received at that address to the bit-bucket.

> existing (bad) precedent).

In the spirit of "Text Dude" here is my try on phrasing this in RFC  
speak:

Implementations SHOULD provide a mechanism to set the value of the  
SOA RNAME to contain a local contact. Implementations MAY default  
this value to "." or, alternatively, MAY configure a mail addressed  
maintained by the vendor. No address records need to be provided for  
the name server.

(If this is not seen as an improvement I do consent with the original  
text)

and while we are at that paragraph. It currently reads:

    If using 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 leakage from the public Internet servers.

Should that first "should" not be a "SHOULD"?

--Olaf

.

---

From: Peter Koch <[email-masked]>
Date: Thu, 14 Sep 2006 15:20:20 +0200

On Wed, Sep 13, 2006 at 09:43:42AM +0200, Olaf M. Kolkman wrote:

> administrator.

ack -- without choosing a "local default", since there's no way to
set this up (too many non-existing "Administrator" mailboxes already ...).

> received at that address to the bit-bucket.

But why then have a "valid" address in RNAME in the first place?

-Peter
.

---

From: Peter Koch <[email-masked]>
Date: Thu, 14 Sep 2006 15:45:11 +0200

{multiple quotes}

> > existing (bad) precedent).

Bingo. RFC 1183 says:

   The root domain name (just ".") may be specified for <mbox-dname> to
   indicate that no mailbox is available.

   [...]

   RP records cause no additional section processing.  (TXT additional section
   processing for <txt-dname> is allowed as an option, but only if it is
   disabled for the root, i.e., ".").

The special meaning is part of the initial spec, precautions to protect "."
are in there -- and this predates RFC 2606.

Tony Finch:

> for SRV records.

Yes, RFC 2782 says

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

Again, it's in the original spec (here and RFC 2052), "." additional
processing is to be avoided (although these paragraphs have to be polished
for 2782bis) and SRV predates RFC 2606.

> Cricket Liu's book, but I could be wrong about that (I don't have a

There was an I-D promoting this, as well. The problem here, as with RNAME,
is that it retroactively applies a special meaning to the "." domain.
For MX RRs thats bad due to the additional section processing, which
should not occur for the SOA RR as per RFC 1035 (although it is done
for MNAMEs)

-Peter
.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 14 Sep 2006 09:22:42 -0700

On Sep 14, 2006, at 6:45 AM, Peter Koch wrote:

>> specified

This text defining a null target does not prevent misuse of the ".",  
even when clearly defined initially in the RR type.

> should not occur for the SOA RR as per RFC 1035 (although it is done

While perhaps not utilized at a high rate, there are many instances  
where a null target is desired.  Using root "." as being analogous to  
"null" has produced undesired traffic elsewhere, specifically in the  
case of SRV records where text defining this name as null should have  
prevented the root traffic.    As this draft is attempting to  
eliminate extraneous traffic, it seems also avoiding this construct  
here and elsewhere in the future could set precedent.  Can there be a  
name established for this construct?  Perhaps something that will not  
be accepted in a DNS query.

-Doug

.