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)
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@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
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@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
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
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@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
On Thu, Nov 25, 2010 at 4:26 AM, Michele Neylon :: Blacknight michele@blacknight.ie wrote:
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 ..
If subdomain.domain.com were bad and domain.com were good, then subdomain.domain.com would be blacklisted, but domain.com and *.domain.com would not be listed. domain.com and *.domain.com would only be listed if the domain and all possible subdomains were bad.
On 25 Nov 2010, at 12:34, SURBL Role wrote:
On Thu, Nov 25, 2010 at 4:26 AM, Michele Neylon :: Blacknight michele@blacknight.ie wrote:
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 ..
If subdomain.domain.com were bad and domain.com were good, then subdomain.domain.com would be blacklisted, but domain.com and *.domain.com would not be listed. domain.com and *.domain.com would only be listed if the domain and all possible subdomains were bad.
Which is fine :)
Unfortunately some other organisations opt to list *.domain.com without thinking it through ..
Discuss mailing list Discuss@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
Michele Neylon :: Blacknight wrote:
On 25 Nov 2010, at 12:34, SURBL Role wrote:
On Thu, Nov 25, 2010 at 4:26 AM, Michele Neylon :: Blacknight michele@blacknight.ie wrote:
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 ..
If subdomain.domain.com were bad and domain.com were good, then subdomain.domain.com would be blacklisted, but domain.com and *.domain.com would not be listed. domain.com and *.domain.com would only be listed if the domain and all possible subdomains were bad.
Which is fine :)
Unfortunately some other organisations opt to list *.domain.com without thinking it through ..
Other organisations ? Other than surbl.org ?
-
Alex Broens -
Jose-Marcio Martins da Cruz -
Kevin A. McGrail -
Michele Neylon :: Blacknight -
SURBL Role