ietf-asrg
[Top] [All Lists]

Re: [Asrg] New draft draft-irtf-asrg-bcp-blacklists-01.txt

2008-03-25 14:28:15
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A couple of remarks from the perspective of an operator of a DNS-based
whitelist (dnswl.org), including some general remarks:

* Large portions of this document apply equally to black- and whitelist.
Therefore it may make sense to enlarge the scope to explictly cover
whitelists as well. The general notion of "DNS-Based Reputation Systems"
would profit even more if whitelists would be explicitly included.

* 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.

* 2.2.3 Removals SHOULD be prompt: Similar to the item above, automated
removals may or may not be a good idea. Considering an Spamhaus-SBL-type
list, this SHOULD for automated removals does not make much sense.

* 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").

* 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).

* Addition to 3.2 and redundancy: nameservers should provide appropriate
glue records, possibly in different TLDs to protect against single-TLD
issues.

* 3.4 Shutdown: Add an item 5 warning against directing nameserver
lookups at some third-party unrelated to the DNSBL operation (eg an ISPs
nameserver), and noting that such behaviour is similar to inflicting a
dDoS).

* 3.5 Listing of special...: "MAY list loopback" vs. "MUST NOT list
127.0.0.1" - does this make sense?

* Proposal: 3.8 Protect against misconfiguration by users: Common types
of misconfigurations include

- - Using wrong (sub-) zones for querying (4.3.2.1.example.com instead of
4.3.2.1.dnsbl.example.com)
- - Downloading a local mirror of the data, but failing to set up the
local nameserver infrastructure appropriately, and thus keeping querying
public nameservers
- - Downloading a local mirror of the data, but misconfiguring the local
nameserver infrastructure to query a locally invented zone name
(4.3.2.1.dnsbl.local) at the public nameservers.
- - Misconfigured local nameservers to not do meaningful caching, thus
heavily increasing load on public nameservers.

To protect against such misconfiguration, DNSBL operators SHOULD make
efforts to contact administrative contacts to remedy the situation, but
SHOULD also prepare to take appropriate steps to protect the operative
infrastructure (ie, to block abusive users from causing further damage).

- -- Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFH6W41xbHw2nyi/okRAiBMAJ4vI+s+Mn6TrPssOhIB02BOgdZ+ywCeP3q/
r6ctnRgoqQ+Wp3w17OQXgkg=
=XuL7
-----END PGP SIGNATURE-----
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg