On May 30, 2007, at 11:23 PM, Graham Murray wrote:
Douglas Otis <[EMAIL PROTECTED]> writes:
The concept is to provide a text file in some standardized format
listing the domain to be avoided. An announcement might be made
that a change occurred to prompt administrators to update their
configurations based upon this list. I would not expect this file
to change so frequently as to be unmanageable. If anything,
domains are remaining fairly flat.
Or use a DNS system, as used by some other systems (eg SpamAssassin
and ClamAV), to indicate when an update is available. Clients
periodically query the DNS, which returns the latest version number
of the file and if this is newer than the one the client currently
holds it can retrieve the new version.
Setting up a zone file under some domain would require someone to
offer this service. That seems logical and even a good idea, but who
would run such a service? This service should be controlled directly
or indirectly by some organization, such as IETF, ICANN, or IANA. It
seems such organizations have more experience setting up a web page,
than a zone file. The web page could even offer a request for
addition or a deletion forms confirmed in some manner, perhaps by a
special "NO_MAIL.<domain>. A IN 128.0.0.2" DNS entry. It would be
rather silly to use a role email address such as postmaster to
confirm a request to indicate a domain does not handle email. A role
email address could confirm a request for removal from the list,
although that should be a very rare request. This web page could
offer an RSS feed or a DNS zone file as an added service, but having
a web page seems like a bare-bones minimum. Perhaps a friendly
company or two could offer the web page information in the form of a
DNS zone file. ; )
The corporate environment established by Microsoft creates a barrier,
as access to DNS may be through RPC. This takes some joy out of
introducing new RRs just to support wildcards. A bad-actor can also
utilize wildcard RRs for staging a DDoS attack.
Wildcards ensure a means to obtain an uncached and relatively large
DNS packet. The DNS question is always included in the answer. The
bad-actor simply needs to ask about random domain names of a maximal
size, where an SSP policy response would then be added to these
labels. Such unusual requests may exceed a maximal DNS packet size,
which could be analogous to pushing someone's fist into their own
face, while saying "Stop hitting yourself." This would be especially
true for likely bloated policy records which always seem destine to
use the greatest number of bits for representing one bit of
information. DNS information is best kept compact, but that will
_not_ happen when describing policy. People like to spell this stuff
out using ASCII. : (
Establishing a list permits a convention for where to first always
look for a record. A list seems like a safe approach, and could also
facilitate domain reputation requests which would be less likely to
clog a DNS cache with junk created by far too prevalent bad-actors. : )
This list should be able to assume a TLD is excluded unless the TLD
indicates otherwise. The lists of domains to be excluded should then
also be able to indicate exceptions made at the TLD, if or when this
is required. A zone file might be able to indicate these exceptions
by assigning a different value to an A record. A normal exclusion
could have an A RR address of 128.0.0.2 whereas the TLD exception
could have the value 128.0.0.4, as example.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
