[SURBL-Discuss] RFC: Changing zone files to wildcarded data format

Alex Broens surbl at alexb.ch
Thu Nov 25 09:12:03 CET 2010


How does it handle abused subdomains?



On 2010-11-23 4:29, SURBL Role wrote:
> 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.com
> subdomain2.domain.com
> subdomain3.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.com
>
>
> legitimate.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.com
> subdomain2.domain.com
>
> but this was good:
>
> NOTLISTED.domain.com (which would not be listed)
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.surbl.org
> http://lists.surbl.org/mailman/listinfo/discuss



More information about the Discuss mailing list