Subject: [dnsop] WGLC for draft-ietf-dnsop-bad-dns-res-02.txt

From: David Meyer <[email-masked]>
Date: Thu, 10 Jun 2004 08:32:08 -0700

Folks

	This note starts the WG Last Call for comments on
	draft-ietf-dnsop-bad-dns-res-02.txt, "Observed DNS
	Resolution Misbehavior". It can be found on  
	
	ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-02.txt

	Please review the document carefully, and send your
	feedback to the list.  Please also indicate whether or
	not you believe that this document is ready to go to the
	IESG. 

	This Last Call will end on 24 June 2004 at 1500 PDT
	(UTC/GMT-7). 

	Thanks,

	Dave & Rob

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

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Fri, 11 Jun 2004 10:32:13 -0400

At 11:32 10/06/2004, David Meyer wrote:

>         Please

I found one error,
Section 2.5.1 first paragraph
s/behind a firewall that prohibits queries to pass through/
   behind a firewall that allows queries to pass through/

Firewall that drops all DNS queries is good for root/gTLD servers 
:-Firewalls that allow queries and drop answers are bad.

>review the document carefully, and send your

Other than this one error, the document looks good and
I support its advancement.

         Olafur

.

---

From: "Barber, Piet" <[email-masked]>
Date: Fri, 11 Jun 2004 14:55:32 -0400

>	not you believe that this document is ready to go to the
2.2.1 Recommendation

[lame name server]... A minimum interval of thirty minutes is RECOMMENDED.

I think 30 minutes is a very long time.  I think a minute is sufficient. 
The goal of the recommendation should be requery abatement, not 
punishment.  One minute penalty box for lame name servers fits the needs 
of limiting the requeries without the punitive aspect of negatively 
caching for 30 minutes.

I believe the document should be modified (including Olafur's remark) 
before sending it along to the IESG.

.

---

From: "Barber, Piet" <[email-masked]>
Date: Fri, 11 Jun 2004 14:55:32 -0400

2.2.1 Recommendation

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Jun 2004 15:49:38 +0300 (EEST)

> 	This Last Call will end on 24 June 2004 at 1500 PDT

The document seems very well written and useful.. However, I see a
rather big problem it being Informational and recommending changes to
the DNS specification behaviour... (below)

bigger issues
-------------

First, this document gives three sets of recommendations with 
uppercase keywords.  This raises two issues:

 1) the category should be at least BCP, or the wording changed. 
(You're making changes/enhancements to the standards track documents!)

 2) have these changes been reviewed and/or adopted by DNSEXT WG?  
(We've produced a similar document like this one at v6ops, and the
IESG stomped on it, because they wanted that the concerned WGs fix the
problem, e.g., by new specifications, not that possible fixes are just
described in an informational RFC -- check out
draft-ietf-v6ops-v6onbydefault in the I-D tracker if interested)

....

   o  Do not make assumptions based on NS RRset order: all NS RRs should
      be treated equally.  (In the case of the "com" zone, for example,
      most of the root servers return the NS record for
      "a.gtld-servers.net" first in the authority section of referrals.
      As a result, this server receives disproportionately more traffic
      than the other 12 authoritative servers for "com".)

==> why don't they randomize it then?  seems like it's the root 
servers that should be fixed here!

nits
----

==> should be updated to have RFC3668 boilerplate

==> should move the keywords from the abstract to the Introduction.

==> all the references are listed as Normative, while some  (e.g., 
[8]) certainly don't qualify as normative.  Perhaps move [7] and [8] 
to informative references?

==> in abstract, s/This Internet-Draft/This memo/ (and similar -- this 
text should also apply when published as RFC!!) [the same in IANA 
considerations]

2.9.1 Recommendation

   It would be desirable for the root name servers not to have to answer
   these queries: they unnecessarily consume CPU resources and network
   bandwidth.  One possibility is for recursive name server
   implementations to produce the Name Error response directly.  We
   suggest that implementors consider the option of synthesizing Name
   Error responses at the recursive name server.  The server could claim
   authority for synthesized TLD zones corresponding to the first octet
   of every possible IP address, e.g. 1., 2., through 255.  This
   behavior could be configurable in the (probably unlikely) event that
   numeric TLDs are ever put into use.

==> does this work for v6 addresses?  maybe need a bit rewording.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.