On Thu, 10 Jun 2004, David Meyer wrote:
> 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).
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
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
