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@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@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss