why manually approving reverse dns is a good idea

[kaniini]

Earlier today, we got a ticket from a customer requesting a reverse DNS being set.

We checked the domain name associated with the RDNS and saw that it was registered with fake information.

We then checked the forward record, and noticed an MX record pointing back to the same forward record associated with the forward record.  This is a typical tactic used by spammers in order to allegedly increase deliverability.

We then connected to port 25 on the VPS and saw PowerMTA running.  PowerMTA, is of course, a software commonly used for mass-mailing...

This gave us probable cause to ask the user what they are planning to do with their server, as well as an opportunity to point out that mass-mailing is a violation of our TOS/AUP.  Unsurprisingly, we haven't heard back.  I suspect we will get a charge-back on the order.

If setting RDNS was automated, and no people were in the loop, we would have failed to catch this.  Therefore, the system works.

 

[SkylarM]

VPSMON Blocks anything over 50 emails in a 1 hour time period for us System works.

 

[Slownode]

Mass mailing is a pain for legitimate users, big mail hosts auto blacklist you if they receive too many mails, but they let in spammers who pay for their services, it's a racket.

 

[jarland]

Nicely done. Honestly more times than not we've found that they freely give themselves away with the hostname field on the order form. As often as you have to figure that they do this stuff, they sure make themselves easy to catch.

 

[VPSCorey]

RDNS does not stop them, I had one guy send 50gb of spam early in the AM and caused me much grief and complaints that had to be dealt with.

 

[kaniini]

RDNS does not stop them, I had one guy send 50gb of spam early in the AM and caused me much grief and complaints that had to be dealt with.

We have other things in place to stop them as well, obviously, such as using sFlow to monitor current network traffic.  Too many hits to port 25 outbound triggers an alarm for us to investigate.

 

[concerto49]

It only works if you have the time to review every rDNS request that goes through etc. It can be a massive overhead with a lot of customers.

 

[kaniini]

It only works if you have the time to review every rDNS request that goes through etc. It can be a massive overhead with a lot of customers.

We have basic techs that basically sit around doing this sort of thing all day, and escalating anything suspicious to me.  It works fine.  The overhead is worth it.

 

[MartinD]

One of the many reasons we don't allow customers to set rDNS themselves. All requests come through the helpdesk.

 

[egihosting]

We do the same. Dealing with hundreds of abuse complaints after a spammer signs up sucks. We are looking at automatically granting automated rDNS for long-term customers, although I think many of these guys will email regardless because they've been trained to do so.

 

[rm_]

"Why hassling each and every of your legitimate customers to catch 1-2 scammers a year is a good idea".

I don't want to ticket a provider for rDNS and then be at their mercy if I'm "allowed" to set that, or not.

Not to mention asking a real person to set a dozen of various silly hostnames (for IRC) would be rather embarassing.

Have a check that it forward-resolves into the same IP, anything beyond that is either your incompetence and inability to set up automation, or you just love so much that "power trip" you get from being able to approve or disapprove one more little thing for others.

 

[MartinD]

Not really, it makes sense to many. Just because a provider doesn't provide automation for a feature doesn't mean they are incompetent or lack the ability to do so.

One less step of automation means one less potential security hole.

 

[kaniini]

"Why hassling each and every of your legitimate customers to catch 1-2 scammers a year is a good idea".

I don't want to ticket a provider for rDNS and then be at their mercy if I'm "allowed" to set that, or not.

Not to mention asking a real person to set a dozen of various silly hostnames (for IRC) would be rather embarassing.

Have a check that it forward-resolves into the same IP, anything beyond that is either your incompetence and inability to set up automation, or you just love so much that "power trip" you get from being able to approve or disapprove one more little thing for others.

On the contrary, rDNS requests are a good indicator of whether or not I want to do business with someone.  If you don't like that rDNS requests are processed by a human, then you're not required to do business with us.  And, frankly, someone requesting rDNS on multiple IPv4's just for IRC vanity hosts (aka DNS spam) is probably not somebody we want on our network anyway.

One of the attractive selling points of our services is explicitly that we do weed out problematic customers proactively, just like I did back in the RapidXen days.  Certainly nothing wrong with applying policies that work...

 

[Aldryic C'boas]

Certainly nothing wrong with applying policies that work...

One thing that always makes me laugh is certain hosts used to shittalk so much about how strict our policies are... and now it seems that just about everyone is using policies I implemented years ago (Not a dig on you neno; just an amusing observation in general :3)

 

[Damian]

We set all reverse DNS requests if proper forward DNS is set. Innocent til proven guilty and things like that, y'know?

 

[Gallaeaho]

We approve our reverse DNS manually as well, and approve most requests, but I'll admit that there are some cases where you end up shaking your head and declining the request.

 

[Gary]

And, frankly, someone requesting rDNS on multiple IPv4's just for IRC vanity hosts (aka DNS spam) is probably not somebody we want on our network anyway.

What utter nonsense. Why wouldn't you want them on your network? You're happy to give them multiple IPv4s, but you're going to be a snob when you find out what they're using them for?

IRC might be a minority interest these days, but plenty of people still use it. If you allow customers to use your services to host IRC stuff, why do you care if they also want to have a vanity rDNS?

 

[kaniini]

What utter nonsense. Why wouldn't you want them on your network? You're happy to give them multiple IPv4s, but you're going to be a snob when you find out what they're using them for?

IRC might be a minority interest these days, but plenty of people still use it. If you allow customers to use your services to host IRC stuff, why do you care if they also want to have a vanity rDNS?

We care about IRC usage that may be problematic (children picking fights with other children).  The attitude portrayed in, "that.stupid.bitch.got.0wned.us" for example, does not reflect the attitude of our target audience.  You see: people with that attitude, tend to attract DDoS attacks by picking fights.  Having to mitigate DDoS attacks caused by children removes available resources for mitigating DDoS attacks against things actually worth mitigating DDoS attacks against.  Yeah, I said that too.  And, I stand by it.

Don't like it?  Feel free to take your business elsewhere.

If you want to school me on "how IRC works" I should mention that I have code in basically every major IRCd and many mainstream IRC clients (the only exception coming to mind would be mIRC, actually), and wrote one of the two mainstream services implementations from scratch.  I think I know how to tell what IRC users I don't want to deal with.  Is it a form of profiling?  You betcha.  But, you see, it works... and I have over a decade of experience dealing with high-risk IRC users.  Be glad I'm willing to deal with them at all.

 

[ryancleary]

Can I have my rdns set to i.dare.you.to.ddos.me?

 

[Aldryic C'boas]

Having to mitigate DDoS attacks caused by children removes available resources for mitigating DDoS attacks against things actually worth mitigating DDoS attacks against.

Seconded.  We will happily assist you in defending against DDoS.  But once we find out that you're instigating the attacks? *cough*robertclarke*cough*, your get kicked to the curb.