on Wed, Dec 01, 2004 at 11:27:54AM -0600, Robert Hayden wrote:

Besides, if customers "need" it to make their mail work, choosing not to do it will be a good indication to your customers that another provider might be more supportive.

Basic non-custom reverse DNS on everything is a "good thing" to put in place regardless.

Just a quick note: it's not a BCP yet, but it's also considered /extremely/ friendly by mail admins and others, if you use a naming convention for your rDNS that is easily placed into access.db and other "right-anchored" string matching mechanisms. e.g., if you have a dynamically assigned DSL range, and want to assign rDNS to it based on the IP, 123-45-67-89.dsl.dyn.example.net is a lot easier to block via rudimentary mechanisms than dsl-dyn-123-45-67-89.example.net which requires regular expression support due to the way sendmail deals with periods in hostnames, etc. In the former example, I can just block all mail from '.dyn.example.net'. In the latter, I need to check the rDNS against a group of regular expressions for /every connection/ which is extremely slow, if effective. So, once you decide to provide rDNS across the board, and provide custom (or "non-generic") rDNS for statically assigned addresses, please also make sure that the naming convention you choose is consistent, friendly to antispam systems, and indicative of the assignment type and/or technology in use, to allow for more fine-tuned policy implementations. Some good actors with sensible naming conventions: personainc.net: all their dynamic hosts are in dyn.personainc.net eatel.net: static are in static.eatel.net, dynamic in dynamic.eatel.net sprint-hsd.net: static are in sta.sprint-hsd.net, dynamic in dyn.sprint-hsd.net or or dhcp.sprint-hsd.net Many others use 'dsl' or 'adsl' or 'cable' etc. as a "subdomain", which is helpful but often doesn't distinguish between static and dynamic at all; others use geographic locations which don't indicate anything useful from an antispam policy perspective. FWIW, 40% or more of the inbound spam mail here comes from hosts with a generic rDNS naming convention (even after DNSBLs and other obvious forgery checks such as hosts using my domain(s)/IP(s) in HELO/EHLO). We simply quarantine any mail from hosts without rDNS at all, and reject all mail from non-whitelisted generic hosts. -- join us! http://hesketh.com/about/careers/web_designer.html join us! hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.html join us!

on Wed, Dec 01, 2004 at 02:41:00PM -0500, Valdis.Kletnieks@vt.edu wrote:

On Wed, 01 Dec 2004 13:16:49 EST, Steven Champeon said:

...

FWIW, 40% or more of the inbound spam mail here comes from hosts with a generic rDNS naming convention (even after DNSBLs and other obvious forgery checks such as hosts using my domain(s)/IP(s) in HELO/EHLO). We simply quarantine any mail from hosts without rDNS at all, and reject all mail from non-whitelisted generic hosts.

Any issues with dealing with the distinction between (for instance) FOO.generic.BAR.(com|net|org) (where generic is the 3rd level) and FOO.generic.BAR.co.uk (where it's a level further down)? Similarly, do you just treat all of *.info or *.biz as a generic swamp? Any other TLD-related issues you've identified in counting up that 40%?

Well, for various reasons I maintain a database of some ~7K or so naming conventions and run my matches against all of them (using a TLD-based right-to-left sort, but still, I know it can be done more efficiently). The practice stems from the days (5/03) when I'd only mapped some 1500 or so conventions. The access.db checks are done right-to-left, too, so Connect:dhcp.vt.edu ERROR:5.7.1:"550 go away, dynamic user" Wouldn't catch 1.2.3.4.dhcp.vt.edu.example.com anyway. All of my matches are currently done on the whole rDNS hostname string, not on a subset, though I'm moving towards a left-anchored subset as it cuts my live pats down from ~7K to ~3200 or so. (e.g., refusing mail from hosts with names like ^h[0-f]{8}\. instead of checking all of the pats that start with h[0-f]{8}). I've got a list of the most common 100 or so left-anchored pat subsets, and hope to put them into practice here soon. So I may have more feedback then. I don't simply treat info/biz as a swamp in practice, no - despite the fact that they're obviously pretty well flooded and swarming :/ So, no TLD-related issues of the sort you seem interested in. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.html join us!

on Wed, Dec 01, 2004 at 03:34:43PM -0500, Valdis.Kletnieks@vt.edu wrote:

On Wed, 01 Dec 2004 15:02:19 EST, Steven Champeon said:

...

Connect:dhcp.vt.edu ERROR:5.7.1:"550 go away, dynamic user"

Given the number of options available at our end, I can hardly blame other sites for considering this a reasonable rule - I can't think of a scenario we can't fix at our end, as long as the user bothers calling our help desk and asks for help fixing it...

Exactly. That's why rDNS has been so useful for us. We can either whitelist exceptions (such as customers of ISPs who have sucky customer service and technical support) or try to educate them. It's (generally) easy to change, it requires static assignment in order to work properly, as an indication of the purpose(s) to which a given IP is put, etc.

(On the other hand, anybody who's filtering certain address blocks because they're our DHCP blocks deserves to be shot, for all the usual reasons and then some..)

Sure, but I can certainly understand why, for example, someone might block all of AOL's dynamic blocks port 25, at least. Or Charter's. Or Cox's, or any of the other sources of massive and constant abuse.

...

Wouldn't catch 1.2.3.4.dhcp.vt.edu.example.com anyway.

Yeah, but that has 'dhcp' at something other than the 3rd level.. ;)

Fair enough :)

I was more interested in whether a rule like '*.dhcp.*.{com|net|org|edu)' (blindly looking at the 3rd level domain and/or the 4th level for the two-letter TLDs) did any better/worse than having to maintain a list of 7K or so - are there enough variant forms that it's worth enumerating, or is it just that enumerating is easier than doing a wildcard?

Ah, I see what you're getting at. Well, I started maintaining my long list of patterns because of the insane complexity of trying to construct simple rules like the above. At one point, I had five or six of them, but it got easier to just run the vetted "generic" hostnames through a quick perl script to generate a regex for each, and then check them all. Surprisingly, on a reasonably fast system with a moderate mail load it runs through the entire set pretty quickly, and it doesn't take up as much RAM as I'd expected it would. I could probably get better stats if you're interested. Quick example, though: of 6936 patterns currently in my list, if you just run a cut on \\ (which catches either '.' or '-' as the next char, for the most part) you get (matches of 20 or more): count first left-hand pattern part ----- ---------------------------- 1572 ^[0-9]+ 206 ^.+ 200 ^host[0-9]+ 179 ^host 145 ^adsl 140 ^ip 121 ^ip[0-9]+ 121 ^.*[0-9]+ 89 ^dsl 83 ^ppp[0-9]+ 74 ^pc[0-9]+ 64 ^ppp 54 ^h[0-9]+ 52 ^dialup 48 ^dhcp 46 ^d[0-9]+ 45 ^dial 43 ^dhcp[0-9]+ 42 ^dsl[0-9]+ 40 ^user[0-9]+ 40 ^[a-z]+[0-9]+ 40 ^[0-f]+ 37 ^.+[0-9]+ 36 ^p[0-9]+ 36 ^[a-z]+ 36 ^.* 32 ^c[0-9]+ 32 ^adsl[0-9]+ 28 ^m[0-9]+ 28 ^cable 25 ^dyn 23 ^dial[0-9]+ 23 ^cable[0-9]+ 23 ^a[0-9]+ 22 ^user 22 ^s[0-9]+ 22 ^[a-z][0-9]+ 21 ^mail[0-9]+ 20 ^u[0-9]+ 20 ^pc 20 ^client It's really not as simple as just blocking .*(dsl|cable|dialup).*; the zombie botnets are sophisticated and they're /everywhere/. So you can't just block the largest 25% most likely sources, as the spammers just rotate through until they find another you aren't testing for. Throw in minor variations within a given ISP, language differences worldwide in naming conventions, and peculiarities in how sendmail's regex support works ('.' isn't picked up by '.+') and you've got a need for at least a few thousand patterns even if you strip off the domain part and try to match on the host part alone. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.html join us!

On Thu, 02 Dec 2004 16:03:55 +0100, Andre Oppermann said:

Reverse zone file for 10.0.0.0/24:

1.0.0.10.in-addr.arpa. IN PTR mail.example.com.

_send._smtp._srv.1.0.0.10.in-addr.arpa. IN TXT "1"

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt

The problem with that is that for *Steven* to benefit from it, *I'd* have to get the appropriate people here to stick in the appropriate stuff in the in-addr.arpa zones for 128.173/16 and 198.82/16. In other words, it suffers from the same deployment problem as SPF records. (Actually, locally, it's harder to deploy because SPF needs one TXT at the top of the zone, which is mostly static and amenable to hand-editing - those __srv records on the other hand are down in zones that are automagically written by software which then needs to be modified to support splatting out the additional TXT record each time...) In other news, we discovered that when we published our SPF record, it managed to push the DNS response over 512 bytes, as we already had several TXT records and 5 NS/A records got returned as well - and we got bit by the usual places that don't do TCP/53 or EDNS0. Anybody else hit that one accidentally? (We ended up jettisoning several TXT's and got it down to 410, so no problem now).

In article <41AF5C33.4050202@nrg4u.com> you write:

You would put in a global wildcard that says no smtp sender here. Only for those boxes being legitimate SMTP to outside senders you'd put in a more specific record as shown above. You probably have to enter some dozen to one hundred servers this way. Sure your reverse zone scripts need some changes but it's only two or three lines.

Ideally you could tell your DNS server in the zone file this:

_send._smtp._srv.*.*.173.128.in-addr.arpa. IN TXT "0" _send._smtp._srv.*.*.82.198.in-addr.arpa. IN TXT "0"

being overidden by more specific information on single IP addresses.

You obviouly do not know how wildcard work in the DNS or you would not have made this suggestion. Please read RFC 1034 and work though Section 4.3.2. Algorithm with a QNAME of _send._smtp._srv.1.1.173.128.in-addr.arpa.

Mark Andrews wrote:

In article <41AF5C33.4050202@nrg4u.com> you write:

...

You would put in a global wildcard that says no smtp sender here. Only for those boxes being legitimate SMTP to outside senders you'd put in a more specific record as shown above. You probably have to enter some dozen to one hundred servers this way. Sure your reverse zone scripts need some changes but it's only two or three lines.

Ideally you could tell your DNS server in the zone file this:

_send._smtp._srv.*.*.173.128.in-addr.arpa. IN TXT "0" _send._smtp._srv.*.*.82.198.in-addr.arpa. IN TXT "0"

being overidden by more specific information on single IP addresses.

You obviouly do not know how wildcard work in the DNS or you would not have made this suggestion. Please read RFC 1034 and work though Section 4.3.2. Algorithm with a QNAME of _send._smtp._srv.1.1.173.128.in-addr.arpa.

The wildcards are in the DNS server zone file for interpretation by the DNS server itself. It would not be published as such because that obviously wouldn't work as you prove. But nothing is preventing BIND or whatever from taking this wildcard record and answering every request with the wildcard "_send._smtp._srv.*" RR if no more-specific exists. This should be relatively straight forward to code. Wouldn't want to touch the code base of BIND but for DJBDNS I could somewhat easily implement it. -- Andre

On Sat, 4 Dec 2004, Henning Brauer wrote:

...

The wildcards are in the DNS server zone file for interpretation by the DNS server itself. It would not be published as such because that obviously wouldn't work as you prove. But nothing is preventing BIND or whatever from taking this wildcard record and answering every request with the wildcard "_send._smtp._srv.*" RR if no more-specific exists. This should be relatively straight forward to code. Wouldn't want to touch the code base of BIND but for DJBDNS I could somewhat easily implement it.

The question remains what to do when zone is transfered between different dns servers (AXFR and such). Even completely syntetic wildcard still needs to be documented in DNS specs. What is proposed above I proposed about year ago privately to Paul Vixie, he said it'll take number of years to push it through the standard, perhaps he can comment more about it now and explain problems with above approach better.

eh? no need to...

Thus we propose expanding the reverse DNS tree with a subdomain with the well known name

_srv

This subdomain MAY be inserted at any level in the DNS tree for IPv4 IN-ADDR.ARPA reverse zones. For IPv6, to limit the number of DNS queries, _srv is only queried at the /128 (host), /64 (subnet) and / 32 (site) level. That way it can either provide information for a specific IP address or for a whole network block. More specific information takes precedence over information found closer to the top of the tree.

So if I want to check on 127.1.2.3, I first do lookup on _srv.3.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.1.127.IN-ADDR.ARPA And if that does not work, I still have to do lookup on _srv.127.IN-ADDR.ARPA Is that how you expect it to work? If that is so, I do not like it because it forces to do these multiple lookups. -- William Leibzon Elan Networks william@elan.net

On Sat, 4 Dec 2004, Henning Brauer wrote:

...

So if I want to check on 127.1.2.3, I first do lookup on _srv.3.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.1.127.IN-ADDR.ARPA And if that does not work, I still have to do lookup on _srv.127.IN-ADDR.ARPA

that is how it works.

...

Is that how you expect it to work? If that is so, I do not like it because it forces to do these multiple lookups.

these lookups are cheap, and with increasing deployment I expect the the vast majority of lookups to have matches on /32 (1st query) or /24 (2nd query).

The problem is going to be for early adaptors - they have to do all 4 lookups because at the time nobody would have these records. There are also problems because sometimes in-addr tree deligation is not properly setup and lookups on it time out (and you have to wait for timeout for each of those lookups).

but anyway, these lookups are reasonably cheap.

There are some here who may disagree if they see this deployed (like say ARIN and other RIRs...) ---------------------------------------------------------------------- Earlier this year I proposed different way of doing above, which maybe better. It involves not checking directly in in-addr tree but instead checking SPF (or some other policy) record on the dns PTR name. So if somebody does not offer proper IN-ADDR support, there is no record there and we need not bother doing this check (and checking just PTR for SMTP connection is going to happen anyway). If PTR record does exist then that is checked and it may then specify that ip can or can not be an SMTP client. Now if somebody needs to enter this record for whole bunch of ips that are not in use (for example 127.1.2.0/24), they can do something like this: *.2.1.127.in-addr.arpa. IN PTR nomail.example.com. nomail.example.com. IN SRV TXT "v=spf1 -all" nomail.example.com. IN A 127.0.0.2 If they have legitimate mail server, the they would likely be wise to enter SPF1 record for such hostname anyway, so nothing new there. The somewhat troublesome situation is when this is a dialup/dsl ISP which has bunch of ips and they actually set each one of them in reverse, i.e. 1.2.1.127.in-addr.arpa. IN PTR dsl-127-1-2-1.example.com. 2.2.1.127.in-addr.arpa. IN PTR dsl-127-1-2-2.example.com. 3.2.1.127.in-addr.arpa. IN PTR dsl-127-1-2-3.example.com. ... And if they have properly setup dns (or otherwise their customers will begin to complain that they can't use irc :), they would also have: dsl-127-1-2-1.example.com. IN A 127.1.2.1 dsl-127-1-2-2.example.com. IN A 127.1.2.2 dsl-127-1-2-3.example.com. IN A 127.1.2.3 .... Now this does mean that you no have to enter an extra record for each one of these and as there is no way to do it with wildcards: dsl-127-1-2-1.example.com. IN A 127.1.2.1 dsl-127-1-2-1.example.com. IN TXT "v=spf1 -all" dsl-127-1-2-2.example.com. IN A 127.1.2.2 dsl-127-1-2-2.example.com. IN TXT "v=spf1 -all" dsl-127-1-2-3.example.com. IN A 127.1.2.3 dsl-127-1-2-3.example.com. IN TXT "v=spf1 -all" ... But I suspect that for most ISPs such dial/dsl zones are not generated by hand, but by some script and modifying such script to add such extra record is not a big deal. P.S. Instead of doing SPF another possibility is to use SRV, i.e. dsl-127-1-2-3.example.com. IN A 127.1.2.3 _client._smtp._tcp.dsl-127-1-2-3.example.com. IN SRV 0 0 0 . --- William Leibzon Elan Networks william@elan.net