|
»
« Return to Thread: DNSBL BCP v.2.0
Re: DNSBL BCP v.2.0
by Matt Sergeant-2
::
Rate this Message:
On 8-Feb-07, at 9:20 PM, Tony Finch wrote:
>> 1.1. DNS-Based Reputation Systems
>>
>> DNSBLs are either public or
>> private. A public DNSBL makes its data available to any party
>> seeking information from the list, but a private DNSBL is used=20
>> solely by an organization for its own use and the data is not
>> made=20
>> available publicly.
>
> There are also commercial DNSBLs which are public except that "any
> party"
> must be willing and able to pay.
I guess better wording might be: "but a private DNSBL restricts who
has access to querying the list."
>> 2.2.1. Listings SHOULD Be Temporary.
>>
>> With the exception of DNSBLs that that are based on data that does
>> not change, such as those include the IP addresses associated
>> with=20
>> a specific country or geographic region, all listings SHOULD be=20
>> temporary so that an entry will time out at some point in the=20
>> future.
>
> IP addresses can move country or region - consider an international
> ISP.
> I don't think there are any certain unchanging attributes of IP
> addresses.
I'd like to get more comment on that. Even international ISPs assign
IP ranges within their country boundaries.
>> 2.2.3. Removals SHOULD Be Prompt.
>>
>> Requests for removal SHOULD be honored without question.
>
> I think this requirement needs more hedging, since it depends on the
> DNSBL listing policy. For example, the requirement is not appropriate
> if the listing is based on who the address space has been allocated
> to,
> especially if the reason is that it has been allocated to criminals.
> In that case you expect to come into conflict with people who are
> listed.
I strongly believe this is covered by the verbiage in this section.
Should a criminal spammer find himself listed in the SBL (for
example), he should be allowed to immediately request removal, and be
granted that. As soon as he spams, he should be immediately relisted.
And the limits on removals be made harder for him/her - see the
second to last sentence in that first paragraph. The intention is to
make innocent listings easy to remove, and criminal listings harder
to remove.
>> 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.
>>
>> When a DNSBL ceases operations and is taken out of circulation,
>> it MUST do so in a graceful manner so that it does not create=20
>> excessive DNS queries or list the entire Internet.
>
> What do you mean by "excessive"? Is this a reference to insane DNS
> clients that generate more traffic when a DNS server goes away?
A typical example of shutting down a DNSBL would involve setting the
TTL to a very high value, to limit the number of queries that result.
>> 4. Security Considerations
>>
>> Like all DNS-based mechanisms, DNSBLs are subject to various=20
>> threats outlined in [RFC 3833].
>
> The recommendations for DNSBL users should be in this section.
> It's worth
> emphasizing that spam is a security problem and that DNSBLs are one
> of many ways to tackle it. DNSBLs usually relate to the SMTP client,
> which can have a limited relationship to the origin of the message if
> the client is relaying or forwarding. However RHSBLs exist as well,
> which have no guaranteed relationship to the client or the origin of
> the message, but can still be useful.
I'm not sure we want to venture into that cesspool :-) But I'm
willing to be persuaded otherwise.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg
>> 1.1. DNS-Based Reputation Systems
>>
>> DNSBLs are either public or
>> private. A public DNSBL makes its data available to any party
>> seeking information from the list, but a private DNSBL is used=20
>> solely by an organization for its own use and the data is not
>> made=20
>> available publicly.
>
> There are also commercial DNSBLs which are public except that "any
> party"
> must be willing and able to pay.
I guess better wording might be: "but a private DNSBL restricts who
has access to querying the list."
>> 2.2.1. Listings SHOULD Be Temporary.
>>
>> With the exception of DNSBLs that that are based on data that does
>> not change, such as those include the IP addresses associated
>> with=20
>> a specific country or geographic region, all listings SHOULD be=20
>> temporary so that an entry will time out at some point in the=20
>> future.
>
> IP addresses can move country or region - consider an international
> ISP.
> I don't think there are any certain unchanging attributes of IP
> addresses.
I'd like to get more comment on that. Even international ISPs assign
IP ranges within their country boundaries.
>> 2.2.3. Removals SHOULD Be Prompt.
>>
>> Requests for removal SHOULD be honored without question.
>
> I think this requirement needs more hedging, since it depends on the
> DNSBL listing policy. For example, the requirement is not appropriate
> if the listing is based on who the address space has been allocated
> to,
> especially if the reason is that it has been allocated to criminals.
> In that case you expect to come into conflict with people who are
> listed.
I strongly believe this is covered by the verbiage in this section.
Should a criminal spammer find himself listed in the SBL (for
example), he should be allowed to immediately request removal, and be
granted that. As soon as he spams, he should be immediately relisted.
And the limits on removals be made harder for him/her - see the
second to last sentence in that first paragraph. The intention is to
make innocent listings easy to remove, and criminal listings harder
to remove.
>> 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.
>>
>> When a DNSBL ceases operations and is taken out of circulation,
>> it MUST do so in a graceful manner so that it does not create=20
>> excessive DNS queries or list the entire Internet.
>
> What do you mean by "excessive"? Is this a reference to insane DNS
> clients that generate more traffic when a DNS server goes away?
A typical example of shutting down a DNSBL would involve setting the
TTL to a very high value, to limit the number of queries that result.
>> 4. Security Considerations
>>
>> Like all DNS-based mechanisms, DNSBLs are subject to various=20
>> threats outlined in [RFC 3833].
>
> The recommendations for DNSBL users should be in this section.
> It's worth
> emphasizing that spam is a security problem and that DNSBLs are one
> of many ways to tackle it. DNSBLs usually relate to the SMTP client,
> which can have a limited relationship to the origin of the message if
> the client is relaying or forwarding. However RHSBLs exist as well,
> which have no guaranteed relationship to the client or the origin of
> the message, but can still be useful.
I'm not sure we want to venture into that cesspool :-) But I'm
willing to be persuaded otherwise.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
Asrg mailing list
Asrg@...
https://www1.ietf.org/mailman/listinfo/asrg
« Return to Thread: DNSBL BCP v.2.0
| Free embeddable forum powered by Nabble | Forum Help |
