The proposed change:
In order to more effectively blacklist abused subdomains, we would
like to get feedback on changing the SURBL zone file data format to
use wildcards. Currently the records look like this canonically:
domain.com (actual result codes not shown)
For wildcarding under rbldnsd, the record would look like this:
.domain.com
For wildcarding under BIND, the record would expand to two:
*.domain.com
domain.com
The above would be the case if both domain.com and all of its
subdomains were to be listed, which is the equivalent functional case
now. For the BIND version of the zone file, it would generally mean a
doubling of file size.
In the highly unusual, exceptional case that only an unqualified
domain were to be listed, the future record would look like for both
rbldnsd and BIND:
domain.com
In the new case that a subdomain would be listed, the record would
look like this for both rbldnsd and BIND:
subdomain1.domain.comsubdomain2.domain.comsubdomain3.domain.com
Impact on list data:
This change would allow SURBL to list more compromized subdomains of
otherwise legitimate sites without impacting the unqualified domain.
As a result, this could lead to more complete coverage of cracked
domains and abused hosts and facilitate better detection of
unsolicited messages that mention such sites.
Currently SURBL does list some abused subdomains, but only for a
relatively limited number of major hosts such as sites at Microsoft,
Google, Yahoo, etc. This change would potentially allow any subdomain
to be listed.
Application support of subdomain handling:
To support the checking of subdomains, applications using SURBL data
would need to be modified to send the fully qualified domain to the
DNS resolver, assuming the typical DNS query method of lookup were
used. Due to the wildcarding of domains generally, the change in
applications to support subdomains could be a simple as not reducing
domains down to their registered (unqualified) level, i.e., just
sending all fully-qualified domains and letting the wildcard in the
DNS zone match them.
In a sense this makes the design of the SURBL applications simpler
since they would no longer need to reduce domains. For example the
two- and three-level-tld lookup tables would no longer need to be
used, simplifying operations somewhat.
Impact on existing nameservers:
The last time this subject was raised, the recalled conclusion was
that caching in nameservers would not be adversely affected since
wildcarded responses are treated correctly in cache for both rbldnsd
and BIND. It would be good to get a confirmation of this, otherwise
there could be performance or resource impacts in nameservers.
Another potential impact is that BIND zone files would be
approximately twice as large as they are presently since BIND doesn't
support a singular, combined record type for a wildcarded subdomain
and its parent domain, unlike rbldnsd. (See the examples above.) This
could increase zone file transfer or rsync times for example. This
could also increase BIND resource utilization.
Most nameservers use rbldnsd, however. rbldnsd systems may be less
affected. The impact on rbldnsd zone file size is much less than the
doubling in BIND, for example.
Other impacts:
One less obvious issue is that a change in zone file format could
adversely impact applications that use the zone file not in a
nameserver. For example reading the data into a database may require
that some filtering be added in order to remove the leading dot, or to
identify the records differently in the database. They may also need
to handle subdomains more generally or in a different way than they
currently do.
Applications in general may need to be updated to take advantage of
the proposed subdomain data. On the other hand, this change should be
backward compatible in that wildcarded domains would continue to match
queries reduced under the original (current) paradigm. In other words
unmodified applications should continue to work as before, with the
downside that they would not detect subdomains handled the new way.
What other impacts could there be? What other changes would be needed?
Would the added subdomain listing capability justify the various
impacts, particularly on application design?
Request for comments:
Given the potential impacts, it seems prudent to ask for comments on
the proposed change. Feedback is welcomed.
Additional examples:
For a full domain owned by the bad guy the listing would be:
.badguy.com (rbldnsd)
*.badguy.com (BIND)
badguy.com (BIND)
For a cracked subdomain, the listing would be:
cracked.legitimate.comlegitimate.com would not be listed.
domain.com would almost never be listed in the rbldnsd file, but
almost always in BIND.
domain.com would usually not be listed for a cracked file, except in
the very unusual case
that these were bad:
domain.com (unqualified)
subdomain1.domain.comsubdomain2.domain.com
but this was good:
NOTLISTED.domain.com (which would not be listed)
