|
»
« Return to Thread: DNSBL BCP v.2.0
Re: Re: DNSBL BCP v.2.0
by Matt Sergeant-2
::
Rate this Message:
On 8-Feb-07, at 7:27 PM, Frank Ellermann wrote:
>> create and maintain DNS-based reputation systems ("DNSBL") of IP
>> addresses and domains identified as problem sources of email.
>> These
>
> Some DNSBLs are in fact "DNS based lists" used for other purposes
> like Geo location. If you haven't done it later you could note
> that you're not talking about the general "DNSBL" concept.
I think we entirely cover that under 2.2.1. Please let us know if you
think we don't.
>> 7. What are the demographics and quantity of the list's user
>> base?
>
> How are admins supposed to evaluate this ? Sounds bogus for me.
Certainly easy to lie about, but a BCP doesn't cover lying. It could
certainly be stated on the DNSBL's web page, or could be stated on a
separate page on whichdnsbl.com (yes, I made that up, though it is
available!).
>> 9. What do your peers or members of the Internet community say
>> about the list.
>
> They all say it's bad for various conflicting reasons, none of them
> related to any incident in the last five years.
:-) Not sure how we could encode that in a BCP.
>> If a system or network administrator allows a third party to make
>> blocking decisions for its network, then the administrator MUST
>> understand the policies and practices of those third parties
>> because responsibility for blocking decisions remain ultimately
>> with the administrator.
>
> Yes. And actually a list does NEVER make blocking decisions for a
> list user, because nobody is forced to use it. How about "uses the
> proposals of a third party to make blocking decisions".
Not sure which part you think is badly worded here. Please elaborate.
>> These guidelines address public DNSBLs only and do not apply to
>> privately operated DNSBLs.
>
> s/do/may/ ? Some proposals should also make sense for private lists.
Possibly, but that is not the intention, and is not something we
could BCP about IMHO. If a private entity wishes to follow these
ideas then that's fantastic, but not what this BCP is about.
>> Therefore readers should be aware that this document
>> does not necessarily represent the consensus of the
>> entire ASRG.
>
> Is that necessary ? As a BCP it will have IETF consensus no matter
> what the ASRG situation might be.
I think this is just draft preamble, required for discussion here.
>> public through a mechanism such as the DNSBL's web site. A DNSBL
>
> s/through a mechanism such as/on / No nonsense please, if it has no
> Web site it's anyway bogus.
It's entirely conceivable that a DNSBL's public presence might be
purely a yahoo-groups mailing list, or NANABL, or some-such. With
FAQs and listing criteria regularly published to such locations.
>> Availability of documentation concerning a DNSBL SHOULD NOT be
>> dependent on the continued operation of DNS for the DNSBL zone
>> file.
>> In other words, if the DNSBL documentation is located at
>> http://example.com/dnsbl/, the documentation web site SHOULD
>> remain
>> available even if the DNSBL zone file is not available.
>
> I don't get this, if the list works like 2.0.0.127.example.net,
> then the
> accompanying Web site SHOULD be located at http://example.net
> Otherwise
> the list is bogus and SHOULD NOT be used. Of course it's fine if
> it has
> other URLs for its policy.
There are major problems with this. What if you decide to stop
running the DNSBL? See section 3.2. I see no reason to remove this
section.
>> With the exception of DNSBLs that that are based on data that does
>> not change, such as those include the IP addresses associated with
>> a specific country or geographic region
>
> s/include/listing/ (?)
Good catch. Thank you.
>> future. For more aggressive spammers (e.g., those operating their
>> own ISP) the temporary period MAY be as much as six (6) months.
>
> + own ISP) the temporary period could be considerably longer (e.g.,
> + weeks) as stated in the listing policy.
>
> I don't get the idea of an arbitrary magic number "6 months". For a
> list with say bogon IPs it would be "as long as necessary", unlimited.
> You address this later, but IMO no fixed limit also here is clearer.
We've mulled over this a lot. Gone back and forth. In the end we said
6 months because if we put no limit on then it's no help - a DNSBL
could just set the limit at 30 years. 6 months is reasonable for a
long listing, and this is very well covered by the last point in this
section - that a temporary listing can easily be extended by (for
example) receiving more spam from this IP/range.
>> However, longer periods SHOULD NOT be used since it is possible
>> that an IP address or domain can change hands, possibly being
>> allocated to a non-abusive user.
>
> Add "unless it's the stated list policy to cause collateral damage
> for users getting their IPs from spam-supporting organizations."
Even the organisation can change hands. See above.
>> 2.2.5. Removals SHOULD Be Possible in Absence of List Administrator.
>
>> Removals SHOULD be possible in the absence of the list
>> administrator.
>
> Delete this line.
Yup.
>> The recommended approach is to put the DNSBL in its own second
>> level domain, and then point the DNS NS records for that second
>> level domain to 127.255.255.255. The TTL for that record
>> should be
>> set at the maximum allowed period of one week.
>
> Intersting, many DNS details are still a kind of mystery for me, users
> would then try to ask a name server at 127.255.255.255, and because
> that's a broadcast address on their own LAN they'd get an error, is
> that the idea ? Was that concept already tested anywhere ?
It has been discussed both here and in many other places.
>> "<query>.dnsbl.example.com" rather than "<query>.example.com".
>
> That's what I meant above, http://dnsbl.example.com for the Web site,
> and other URLs for the case when the list is terminated. Ideally as
> redirection (moved permanently) to the more persistent URL.
Not sure what you mean here. Hopefully you're agreeing with what I
said above.
>> The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and
>> any other permanently reserved or special-use IP addresses.
>
> No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT
> abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please
> limit it as good as you can).
list != result. We're not talking about the result IP here. Just what
can be present in the DNSBL.
>> Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8
>
> Indeed, and anything else is just wrong.
Possibly/probably yeah. But this BCP doesn't cover that.
>> In particular, most DNSBLs use a positive response for 127.0.0.2
>
> s/most/many/ and s/for/of/
I think "most" is fine. The second change is correct.
> You should also mention that lists SHOULD
> support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the
> opposite (never listed), without ever returning 127.0.0.1 as a result.
Good point. We'll consider adding that. It's a good test for DNSBL
validity.
>> for this. See reference [DNSBL-EMAIL] for additional information.
>
> Maybe that's not more needed if you explain the trivial concepts here.
>
>> [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and
>> Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005
>
> If you keep RFC 1918 you've to list it as reference. RFC 2119 should
> be noted as normative - I think you've somehow lost the section with
> normative references.
>
> Nice draft, I like it, thanks,
Thanks for your comments. Very useful.
Matt.
______________________________________________________________________
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
>> create and maintain DNS-based reputation systems ("DNSBL") of IP
>> addresses and domains identified as problem sources of email.
>> These
>
> Some DNSBLs are in fact "DNS based lists" used for other purposes
> like Geo location. If you haven't done it later you could note
> that you're not talking about the general "DNSBL" concept.
I think we entirely cover that under 2.2.1. Please let us know if you
think we don't.
>> 7. What are the demographics and quantity of the list's user
>> base?
>
> How are admins supposed to evaluate this ? Sounds bogus for me.
Certainly easy to lie about, but a BCP doesn't cover lying. It could
certainly be stated on the DNSBL's web page, or could be stated on a
separate page on whichdnsbl.com (yes, I made that up, though it is
available!).
>> 9. What do your peers or members of the Internet community say
>> about the list.
>
> They all say it's bad for various conflicting reasons, none of them
> related to any incident in the last five years.
:-) Not sure how we could encode that in a BCP.
>> If a system or network administrator allows a third party to make
>> blocking decisions for its network, then the administrator MUST
>> understand the policies and practices of those third parties
>> because responsibility for blocking decisions remain ultimately
>> with the administrator.
>
> Yes. And actually a list does NEVER make blocking decisions for a
> list user, because nobody is forced to use it. How about "uses the
> proposals of a third party to make blocking decisions".
Not sure which part you think is badly worded here. Please elaborate.
>> These guidelines address public DNSBLs only and do not apply to
>> privately operated DNSBLs.
>
> s/do/may/ ? Some proposals should also make sense for private lists.
Possibly, but that is not the intention, and is not something we
could BCP about IMHO. If a private entity wishes to follow these
ideas then that's fantastic, but not what this BCP is about.
>> Therefore readers should be aware that this document
>> does not necessarily represent the consensus of the
>> entire ASRG.
>
> Is that necessary ? As a BCP it will have IETF consensus no matter
> what the ASRG situation might be.
I think this is just draft preamble, required for discussion here.
>> public through a mechanism such as the DNSBL's web site. A DNSBL
>
> s/through a mechanism such as/on / No nonsense please, if it has no
> Web site it's anyway bogus.
It's entirely conceivable that a DNSBL's public presence might be
purely a yahoo-groups mailing list, or NANABL, or some-such. With
FAQs and listing criteria regularly published to such locations.
>> Availability of documentation concerning a DNSBL SHOULD NOT be
>> dependent on the continued operation of DNS for the DNSBL zone
>> file.
>> In other words, if the DNSBL documentation is located at
>> http://example.com/dnsbl/, the documentation web site SHOULD
>> remain
>> available even if the DNSBL zone file is not available.
>
> I don't get this, if the list works like 2.0.0.127.example.net,
> then the
> accompanying Web site SHOULD be located at http://example.net
> Otherwise
> the list is bogus and SHOULD NOT be used. Of course it's fine if
> it has
> other URLs for its policy.
There are major problems with this. What if you decide to stop
running the DNSBL? See section 3.2. I see no reason to remove this
section.
>> With the exception of DNSBLs that that are based on data that does
>> not change, such as those include the IP addresses associated with
>> a specific country or geographic region
>
> s/include/listing/ (?)
Good catch. Thank you.
>> future. For more aggressive spammers (e.g., those operating their
>> own ISP) the temporary period MAY be as much as six (6) months.
>
> + own ISP) the temporary period could be considerably longer (e.g.,
> + weeks) as stated in the listing policy.
>
> I don't get the idea of an arbitrary magic number "6 months". For a
> list with say bogon IPs it would be "as long as necessary", unlimited.
> You address this later, but IMO no fixed limit also here is clearer.
We've mulled over this a lot. Gone back and forth. In the end we said
6 months because if we put no limit on then it's no help - a DNSBL
could just set the limit at 30 years. 6 months is reasonable for a
long listing, and this is very well covered by the last point in this
section - that a temporary listing can easily be extended by (for
example) receiving more spam from this IP/range.
>> However, longer periods SHOULD NOT be used since it is possible
>> that an IP address or domain can change hands, possibly being
>> allocated to a non-abusive user.
>
> Add "unless it's the stated list policy to cause collateral damage
> for users getting their IPs from spam-supporting organizations."
Even the organisation can change hands. See above.
>> 2.2.5. Removals SHOULD Be Possible in Absence of List Administrator.
>
>> Removals SHOULD be possible in the absence of the list
>> administrator.
>
> Delete this line.
Yup.
>> The recommended approach is to put the DNSBL in its own second
>> level domain, and then point the DNS NS records for that second
>> level domain to 127.255.255.255. The TTL for that record
>> should be
>> set at the maximum allowed period of one week.
>
> Intersting, many DNS details are still a kind of mystery for me, users
> would then try to ask a name server at 127.255.255.255, and because
> that's a broadcast address on their own LAN they'd get an error, is
> that the idea ? Was that concept already tested anywhere ?
It has been discussed both here and in many other places.
>> "<query>.dnsbl.example.com" rather than "<query>.example.com".
>
> That's what I meant above, http://dnsbl.example.com for the Web site,
> and other URLs for the case when the list is terminated. Ideally as
> redirection (moved permanently) to the more persistent URL.
Not sure what you mean here. Hopefully you're agreeing with what I
said above.
>> The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and
>> any other permanently reserved or special-use IP addresses.
>
> No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT
> abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please
> limit it as good as you can).
list != result. We're not talking about the result IP here. Just what
can be present in the DNSBL.
>> Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8
>
> Indeed, and anything else is just wrong.
Possibly/probably yeah. But this BCP doesn't cover that.
>> In particular, most DNSBLs use a positive response for 127.0.0.2
>
> s/most/many/ and s/for/of/
I think "most" is fine. The second change is correct.
> You should also mention that lists SHOULD
> support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the
> opposite (never listed), without ever returning 127.0.0.1 as a result.
Good point. We'll consider adding that. It's a good test for DNSBL
validity.
>> for this. See reference [DNSBL-EMAIL] for additional information.
>
> Maybe that's not more needed if you explain the trivial concepts here.
>
>> [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and
>> Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005
>
> If you keep RFC 1918 you've to list it as reference. RFC 2119 should
> be noted as normative - I think you've somehow lost the section with
> normative references.
>
> Nice draft, I like it, thanks,
Thanks for your comments. Very useful.
Matt.
______________________________________________________________________
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 |
