Hi Evgeniy, thanks for your answers. On 11/18/09 9:59 PM, Evgeniy Khramtsov wrote: > Peter Saint-Andre wrote: >> How is your DNSBL built? > > Currently it is build manually, no reporting yet.
OK. My question really was: what are the criteria for adding a domain to the blacklist? See a list of possible criteria at the end of this message. > It is located on > dnsbl.jabber.ru and is maintaining according to DNSxL I-D. I assume you mean this: http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-08 And not this: http://tools.ietf.org/html/draft-church-dnsbl-harmful-01 :) >> What are the inputs? > > The input currently is server DNS names (i.e. only s2s so far). The > format is described in the DNSxL I-D: > http://tools.ietf.org/html/draft-irtf-asrg-dnsbl-08#section-3 >> How does the operator of an XMPP service find out if their domain or >> IP address is listed? Do you return a particular stream error to >> entities that are on the DNSBL? > > Those are not yet implemented. It's on my TODO list. >> How does a service remove itself from the list? Where is the list >> maintained and by whom? > > There is no such functionality yet. Please understand, we ran it as a > testing service only for our purposes. However, everyone is able to > maintain his own list. There are also software available for that > purpose (rbldnsd for example). By the way, there is I-D available which > discusses guidelines for the management of public DNSBLs by their > operators - http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-05 Thanks for the links. >> How does someone access the list? > > Everybody can access it via DNS client ;) OK. How do they discover its address? I don't see an SRV record defined for DNSBLs. Do people simply need to know that the address is dnsbl.jabber.ru? >> What if the machine on which the DNSBL is located gets hacked? Does >> this introduce a single point of failure or attack for the XMPP network? > > If you have only one DNSBL configured in your service then, yes, you are > in troubles. However typically, you should have multiple DNSBLs > configured (and even weighted and ranged) to get rid of that kind of > bottle-neck. True. >> Personally I would prefer a decentralized technology like XEP-0268 to a >> centralized DNSBL. >> > > I read the XEP and didn't find where it is more decentralized than > DNSBLs. In my experience with email, DNSBLs tend to become centralized (people trust only one or two). If we can avoid that in XMPP, I would be happier. I am especially concerned about the "arbitrary operational decisions by blacklist operators" mentioned in draft-church-dnsbl-harmful-01 because I have run into those for email. > Also, as I understand the XEP only describes reporting technics. You're right. What a service does based on reports is a matter of local service policy. Reports could even be used as input to DNSBLs. In general, I think we need to carefully consider whether we think DNSBLs are helpful. Typically, blacklists work only if you have a somewhat strong sense of identity. This is not generally the case for email (which is why whitelists work better there), but I think that we might be able to make DNSBLs work on the XMPP network. However, if we do so, let's at least try to do it intelligently. I suggest that we read draft-church-dnsbl-harmful-01 and other relevant information to arrive at some reasonable policies and procedures. I'd also like some feedback on my proposal for server reputations. A server is not boolean "good" or "bad", but probably some shade of grey. I think that a new server on the network would start with a score of zero. Its score would go up for: 1. CA-issued certificate 2. CAPTCHA or other hurdle required for account registration 3. Support for incident reporting (XEP-0268) 4. TLS succeeds (with SASL EXTERNAL or Dialback) 5. Longevity (e.g., 1 point for each year on the network) 6. Admins answer mail sent to [email protected] 7. Proper DNS SRV records 8. Website with contact addresses 9. Other good things (let's define these) Its score would go down (negative) for: 1. Actively sends spam 2. Generates denial of service attacks 3. Other abusive activities (let's define these) My main concern here is that we have objective criteria for scoring servers, not arbitrary decisions by DNSBL operators. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
