The CSV-DNA Accreditation Report string defines the "recommendation"
field as:
1. 'A' for Strongly Recommended
2. 'B' for Recommended
3. 'C' for Unknown
4. 'D' for Not Recommended
5. 'E' for Strongly Not Recommended
I think we need separate responses for:
Unknown
Specified domain is unknown to the Accreditation Service.
This could be semantically the same as an NXDOMAIN response
from the DNS server, but providing a positive response from
the DNS rather than a negative response.
Neutral
Specified domain is known to the Accreditation Service but
the Service has no opinion on the domain, perhaps due to
insufficient data or inconsistent data.
I'd like to discuss the merits of one more:
Retracted
Specified domain is known to the Accreditation Service but
the Service now retracts all previous recommendations.
Alternatively, the "retracted" indication could be specified as a
separate field, with or without a "recommendation" field.
The underlying issue is how we convey record-level negative responses
and error cases. I'm concerned about the (IMHO) laissez-faire reliance
on negative DNS responses that seems to becoming standing practice,
starting with the DNSBLs and now working its way into Domain Keys and
other places. The caching behavior of negative responses is different,
and there are still implementations in the wild that forget to timeout
negative responses (or ignore the TTL in the SOA). Fault diagnosis is
also difficult when you cannot distinguish between a legitimate "I don't
know" response and querying the wrong server. (You could argue that the
DNSBLs should have returned SERVFAIL to indicate "unlisted," rather than
an Authoritative NXDOMAIN, but the horse left that barn a long time ago.)
Hence when we're designing new records, I'd like to build in
well-defined "I don't know" and "changed my mind" responses into the
record, limiting the use of the Authoritative NXDOMAIN to really mean
"Domain Does Not Exist."
<csg>