* 2.2.1 Listings SHOULD be temporary: IMO this section should be dropped
- - it describes a certain policy which may or may not fit the purpose of
a particular DNSBL.
Perhaps, listings based on the observed behavior of the IP should be
temporary. If it's listed because it sends spam, it may well stop
sending spam but if it's listed because it's DHCP space or because
it's in Korea, it won't.
* 3.1 DNSBL Query Root Domain SHOULD be a subdomain: It should be
defined how best to differentiate multiple (possibly related) DNSBLs
under a common domain ("purposeA.dnsbl.example.com" and
"purposeB.dnsbl.example.com" vs. "dnsblA.example.com" and
"dnsblB.example.com").
That's in the other document that describes the mechanics. See the
ASRG Wiki for a copy of it.
* 3.2 DNSBLs SHOULD be Adequately Provisioned: For public use, that
should rather be a MUST. "Redundancy" should further be clarified
(number, net-topological location and vendor/versions of software).
This doesn't seem like the right place for a treatise on DNS ops.
Adequate should be adequate.
* Addition to 3.2 and redundancy: nameservers should provide appropriate
glue records, possibly in different TLDs to protect against single-TLD
issues.
Ops again.
* Proposal: 3.8 Protect against misconfiguration by users: Common types
of misconfigurations include
way more boneheaded things than any of us can possible imagine. Don't
see that this is a reasonable thing for people to ask, particularly if
a DNSBL gets a lot of use. I can also report from experience that there
are plenty of places that misuse a DNSBL and are completely impossible
to contact or correct.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg