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

Alex Broens surbl at alexb.ch
Thu Nov 25 09:14:01 CET 2010


Pls ignore my comment, not quite awake yet.

On 2010-11-25 9:12, Alex Broens wrote:
> 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
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.surbl.org
> http://lists.surbl.org/mailman/listinfo/discuss



More information about the Discuss mailing list