Subject: [DNSOP] draft-ietf-dnsop-default-local-zones-01

From: Doug Barton <[email-masked]>
Date: Wed, 06 Jun 2007 14:03:01 -0700

Howdy,

I finally had a chance to take a serious look at this draft with an
eye toward implementing its recommendations for FreeBSD's default name
server configuration, and noticed that it isn't quite in final form,
so I decided to take a crack at improving the text. Along the way I
have some additional recommendations regarding name spaces that I
think should be included, some of which I realize might be
controversial. :)

I should point out that I did read the threads on this paper already,
and I apologize in advance for not giving full credit to others who
have advanced some of these suggestions already. Where that is true
please read it as my agreeing with their suggestion, rather than
trying to take credit for their work.

To be explicit, I do support the draft moving forward once it's in
better shape, and I support the proposed BCP status.

Because my edits are somewhat extensive, rather than go line by line
I've provided diffs in both unified and context formats:

http://dougbarton.us/draft-ietf-dnsop-default-local-zones-01.udiff.txt
http://dougbarton.us/draft-ietf-dnsop-default-local-zones-01.cdiff.txt

I could provide line by line suggestions if that's preferred.

I also have a few comments, questions and suggestions that I didn't
include in the text.

Abstract
Is it preferred to use 2119-style SHOULDs, etc.; and brackets around
the references in the abstract, or is that text allowed to be more
free form?

Section 3, paragraph 3
I am not sure what is meant by "the same NS and SOA records as used on
the public Internet servers" in the first sentence. I feel like Mark
is trying to make a useful point, and I'm missing it.

I also concur with the various protests against using . for the RNAME,
and would suggest instead "nobody.localhost." along with a ref to
2606. That should be sufficiently clear to any human who looks at it,
and also meets the goal of not providing any useful data to a spam bot.

Section 3, paragraph 6
I'm not arguing against this, but I'm curious about your reasoning for
saying the 2 TTL values SHOULD match. It would probably be useful to
expand that text so that implementors could make a more informed
decision.

In Section 4 I struck the first sentence, since it seems redundant.

Section 4.2
I added some white space between the names and descriptions since I
agreed with the earlier suggestion to do this. I also added several
name spaces from 3330 that I think should also be included, and used
255.IN-ADDR.ARPA instead of just the one address per the
recommendation in 1912. It may be relevant to add a ref there, but I
wasn't sure how best to format that. I realize that expanding the list
might not be a popular idea, so I'm perfectly happy to have those
additional zones removed if that's the consensus, but I thought I'd
make the suggestion. In my experience nothing is harmed by adding these.

I think this also opens up a question about the motivation for this
draft. Is it primarily to reduce spurious traffic to the roots and/or
AS112 (certainly a noble goal, don't get me wrong), or is it primarily
to aid operators in configuring helpful defaults? If the latter I
think that including more zones that are highly unlikely to be the
subject of legitimate queries is a good idea. If the former then we
should focus on those zones that are giving the roots/AS112 the most
trouble (which presumably is what Mark has done).

Section 4.3
I agree with the recommendation to add the all 0's address, but
shouldn't ::1 be defined as "localhost," per 1912 (by extension)?

I'm also proposing 2 new sections, 4.6 to include all IPv6 space that
is currently "reserved" by the IETF, and 4.7 for IPv4 space that is
currently "reserved" by IANA, and highly unlikely to be allocated any
time soon. In 4.6 the ...'s in the diff are meant to indicate that the
whole range between the zones above and below the dots should be
included in the final product. Once again, one could easily argue that
this is overkill, but I wanted to open up discussion on why this is or
is not a good idea.

Section 5, paragraph 2
I think the ref to 4291 is meant to be 4193.

Section 5, paragraph 3
I reworded the paragraph on IP6.INT to take current reality into account.

Section 6
I reworded the IANA Considerations to be more clear about what is
being requested. I also condensed the sentence that seemed to be
making a distinction between ICANN and IANA. I know it's a touchy
subject for some people though, so no objections if people want it
worded differently.

Section 7
"When DNSSEC is deployed," *cough* we will want the current contents
of the IANA registry to be delegated insecurely, not necessarily
what's in the doc when it's published.

I hope this is useful, and I look forward to a lively discussion. :)

Doug

-- 

	If you're never wrong, you're not trying hard enough

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Wed, 6 Jun 2007 17:37:56 -0400 (EDT)

> to aid operators in configuring helpful defaults? If the latter I

Putting on my AS112 hat on:  Yes.  Taking it off, yes to both questions.

> Section 4.3
[snipping out proposed inclusion of other space.]

I think I know the gist of what you're trying to do here.

W.r.t inclusion of other address space in the amended and proposed new 
sections, I would say that including *reserved* space as opposed to 
*unallocated* space is a good idea in principle.  I make this distinction, 
because I would hate to see this draft go to the other extreme and propose 
to create a DNS version of a 'bogon-prefix-list', as unallocated space 
does tend to get allocated, and people's bogon filters don't rapidly 
change to suit.  This creates all sorts of nifty routing problems. :-)

wfms

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Wed, 6 Jun 2007 17:37:56 -0400 (EDT)

wfms

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Jun 2007 15:20:02 +1000

> http://dougbarton.us/draft-ietf-dnsop-default-local-zones-01.cdiff.txt

	draft-ietf-dnsop-default-local-zones-02 is current.
 
> the references in the abstract, or is that text allowed to be more

	Abstracts don't normally use 2119-style SHOULDs.
 
> is trying to make a useful point, and I'm missing it.

10.in-addr.arpa.        300     IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800
10.in-addr.arpa.        300     IN      NS      blackhole-1.iana.org.
10.in-addr.arpa.        300     IN      NS      blackhole-2.iana.org.
;; Received 162 bytes from 192.175.48.42#53(blackhole-2.iana.org) in 220 ms

	You want recurive nameservers to be able to detect leakage
	of queries to the above servers then to log that fact.  You
	can only do that if the SOA and NS records are differnet
	(think answer via forwarder).

> agreed with the earlier suggestion to do this.

	Show me the xml.  There should be a way to do a table.

        <t>
          <list>
            <t>0.IN-ADDR.ARPA               /* IPv4 "THIS" NETWORK */</t>
            <t>127.IN-ADDR.ARPA             /* IPv4 LOOP-BACK NETWORK */</t>
            <t>254.169.IN-ADDR.ARPA         /* IPv4 LINK LOCAL */</t>
            <t>2.0.192.IN-ADDR.ARPA         /* IPv4 TEST NET */</t>
            <t>255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */</t>
          </list>
        </t>

> I also added several

> to aid operators in configuring helpful defaults?

	It's to allow the zones to be hard wired in.  It needs to be
	a conservative list.

> If the latter I

	This doesn't fit with the model of the correct answer is
	NXDOMAIN.
	
> this is overkill, but I wanted to open up discussion on why this is or

	Adding reserved space is not a good idea.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Jun 2007 15:20:02 +1000

<t>
          <list>

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Jun 2007 07:18:01 -0400

>             <t>255.255.255.255.IN-ADDR.ARPA /* IPv4 BROADCAST */</t>

There is a way to do a table:

   <texttable>
     <ttcol>Zone</ttcol><ttcol>Description</ttcol>
     <c>0.IN-ADDR.ARPA</c></c>IPv4 "THIS" NETWORK</c>
     <c>127.IN-ADDR.ARPA</c><c>IPv4 LOOP-BACK NETWORK</c>
     <c>254.169.IN-ADDR.ARPA</c><c>IPv4 LINK LOCAL</c>
     <c>2.0.192.IN-ADDR.ARPA</c><c>IPv4 TEST NET</c>
     <c>255.255.255.255.IN-ADDR.ARPA</c><c>IPv4 BROADCAST</c>
   </texttable>

There are details in <http://xml.resource.org/authoring/draft-mrose- 
writing-rfcs.html> (see section 2.3.1.4).

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Jun 2007 07:18:01 -0400

<texttable>

Joe

---

From: [email-masked]
Date: Thu, 7 Jun 2007 14:42:39 +0000

On Thu, Jun 07, 2007 at 07:18:01AM -0400, Joe Abley wrote:
> JoeA

	to borrow a phrase:

	"I'm too young for nroff and too old for xml...
	 I'm generation V(i)!"

--bill

---

From: [email-masked]
Date: Thu, 7 Jun 2007 14:42:39 +0000

to borrow a phrase:

--bill

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Jun 2007 14:57:35 +1000

> and also meets the goal of not providing any useful data to a spam bot.

	Not "nobody.invalid."?

	nobody@localhost is likely to be a real mailbox.
	nobody@invalid should bounce.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Jun 2007 14:57:35 +1000

Not "nobody.invalid."?

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Jun 2007 16:54:22 +1000

Look for draft-ietf-dnsop-default-local-zones-02 in the
	I-D repository soon. 

	In the mean time you can find it here.

	http://members.optusnet.com.au/~marka63/draft-andrews-full-service-resolvers.html

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Jun 2007 16:54:22 +1000

Mark

---

From: [email-masked]
Date: Fri, 8 Jun 2007 15:25:03 +0000

> 	nobody@invalid should bounce.

	why do you think so?

---

From: [email-masked]
Date: Fri, 8 Jun 2007 15:25:03 +0000

why do you think so?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Jun 2007 10:08:25 -0700

> 	nobody@invalid should bounce.

It seems that a domain of "invalid" may not be recognized by its name  
alone as being invalid.  How long will it be before DNS servers and  
applications reliably recognize this domain as being invalid?

There might be a desire in some protocols to publish records that  
points to an invalid hostname.  This could be their method to  
indicate a type of non-existence.  However, this might backfire as  
being seen as being a valid hostname instead.  Applications may also  
attempt to discover a name server for this domain.  What portion of  
this traffic will be mitigated?

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Jun 2007 10:08:25 -0700

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Jun 2007 08:56:07 +1000

> > 	nobody@invalid should bounce.

	a) nobody exists on lots of boxes.  Not all boxes alias nobody
	to something that gets read.  b) localhost is usually correctly
	processes to mean deliver locally. 

	Put (a) and (b) together and you have mail going into a black
	hole.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Jun 2007 08:56:07 +1000