1. In draft-ietf-marid-protocol-02.txt in section 2.1.7 last paragrapths read
" Notice that the wildcard records must be repeated for twice for
every name within the domain: Once for the name, and once to cover
the tree under the the name.
Use of wildcards is discouraged in general as they cause every name
under the domain to exist and queries against arbitrary names will
never return NXDOMAIN."
I see multiple grammer errors in above paragraph as well as some other
problems. In particular:
a. " Notice that the wildcard records must be repated" does not sound right
to me (butenglish is not my first language, I may well be wrong).
I think changing this to just "Notice that wildcard records" would be
better. Additionally extra " " before "Notice" should be removed.
b. "repeated for twice for every name" is not correct, first "for" should
be removed and this changed to "repeated twice for every name"
c. The last paragraph refers to dns server returning NXDOMAIN as indication
that no domain exist with DNS references in the document to RFC1035.
In reality NXDOMAIN is (was?) bind-specific error contruct and not
an error code used for this purpose in IETF DNS specifications.
This error code should be referred to as "RCODE 3" (or RCODE=3)
Please see last paragraph in the comments made by Paul Vixie on his
view of using NXDOMAIN when referring to Verisign's wildcards dns abuse:
http://www.cctec.com/maillists/nanog/historical/0310/msg00957.html
Note that same also applies to other parts of the document, in particular
I see NXDOMAIN used in section 3.4 next to last paragraph. Additionally
in same section in last paragraph refers to server failure error code
as "SERVFAIL". This is also BIND specific construct and reference
should be referred to as "RCODE 2" (see RFC1035).
At the same time I note that RFC2929 then set "NXDomain" as proper
name of the DNS RCODE 3 and "ServFail" as proper name for RCODE 3
when registering them with IANA and this is now listed at
http://www.iana.org/assignments/dns-parameters.
But none of these documents are referenced from the protocol draft.
I recommend that if use of NXDOMAIN and SERVFAIL is retained in the
document, that names be replaced with "NXDomain" and "ServFail" with
reference to either RFC2929 or to IANA dns parameters assignments url.
Or alternatively the names "NXDOMAIN" and "SERVFAIL" can be removed
and replaced with "RCODE 3" and "RCODE 2" with reference to RFC1035
2. In section 2.1 ("Publishing"), the paragraph reads:
"The previous example might be published easily via this line in a
domain file".
"domain file" is a vague reference, please at the very least replace
with "domain zone file".
Futher the section 2.1 ends as
"When published via TXT records it is still published
directly at the domain name, even though other TXT records, for
other purposes may be published there".
I believe it should be added her also that use of the same record type
for multiple puposes is discouraged.and wide use such practice poses
a danger to dns system.
3. In section 2.1.1 "SPF DNS RR Type" paragraph says
"Sender-ID compliant mail originating zones MUST publish SPF2 type
records, and MAY publish TXT records that have identical content"
I believe more emphasis is needed that TXT rect must be same as new
DNS SPF type record and suggest changing this to:
"Sender-ID compliant mail originating zones MUST publish SPF type
records if such record type is supported and MAY publish TXT records.
If both TXT and SPF type records are published for the same zone the
content of these records MUST be identical."
4. In next paragraph in 2.1.1 it says
"A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup
TXT record at the same time, or wait for negative answer. SPF2 type
SHOULD be used if available"
Why does it specifically refer to "negative answer", what is so bad
about "positive answer"? I think this all should rephrased to make
it more clear:
"A Sender-ID compliant MTA MUST look up SPF RR type. It MAY lookup
TXT record at the same time or after receiving negative answer to
SPF RR type query. If data from both SPF and TXT records is received
then SPF RR type record data SHOULD be used.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/