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

Michele Neylon :: Blacknight michele at blacknight.ie
Thu Nov 25 13:26:11 CET 2010


I would have concerns about which domains were wildcarded and how that was decided.
We have already been impacted by a particular company blacklisting *.blacknight.com due to an issue with one subdomain .. 


On 23 Nov 2010, at 03: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

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon

PS: Check out our latest offers on domains & hosting: http://domainoffers.me/
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845




More information about the Discuss mailing list