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

Kevin A. McGrail KMcGrail at PCCC.com
Thu Nov 25 13:22:45 CET 2010


As a public nameserver, I support this change.  It makes the data more accurate and if we need more resources, sobeit.

Happy Thanksgiving.

Regards,
KAM

"SURBL Role" <surbl.role at gmail.com> 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