Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are "mass-listed" the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing? That said, it is best practice to set ptr records even for your unassigned ip space --srs (htc one x) On 10-Jan-2013 8:30 AM, "Julian DeMarchi" <julian@jdcomputers.com.au> wrote:
Heya,
I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much.
I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase.
This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer?
Their removal process is also a joke. As we are "mass-listed" the normal removal process does not apply. I've used their contact form but doubt I'll get a response.
Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2].
Regards,
Julian
0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
On 01/10/2013 01:06 PM, Suresh Ramasubramanian wrote:
Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing?
Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue.
That said, it is best practice to set ptr records even for your unassigned ip space
Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts. --julian
Ask your customers what I asked you. Are they actually seeing email blocked and bounced because of that spam rats listing. Also it is your choice whether or not to follow best practices, it is spam rats choice to block mail based on whatever they like, and it is the choice of some random email Admin or the other to block mail based on spam rats.. Which is something I wouldn't recommend to people running a production mail system, but we'll.. --srs (htc one x) On 10-Jan-2013 8:40 AM, "Julian DeMarchi" <julian@jdcomputers.com.au> wrote:
On 01/10/2013 01:06 PM, Suresh Ramasubramanian wrote:
Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing?
Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue.
That said, it is best practice to set ptr records even for your unassigned ip space
Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts.
--julian
On 01/10/2013 01:16 PM, Suresh Ramasubramanian wrote:
Ask your customers what I asked you. Are they actually seeing email blocked and bounced because of that spam rats listing.
They are yes. Emails are being blocked due to the listing on spamrats. For our colo ranges we do not set PTRs by default. I do for the hosts I run. I do beleive in BCP. :)
One $GENERATE in bind should take care of that, and save what looks like the usual extra long nanog thread? What does it cost you not to do it? On Thursday, January 10, 2013, Julian DeMarchi wrote:
On 01/10/2013 01:16 PM, Suresh Ramasubramanian wrote:
Ask your customers what I asked you. Are they actually seeing email blocked and bounced because of that spam rats listing.
They are yes. Emails are being blocked due to the listing on spamrats.
For our colo ranges we do not set PTRs by default. I do for the hosts I run. I do beleive in BCP. :)
-- --srs (iPad)
Any moron can run a DNSBL. Many morons do. But that doesn't mean that anyone actually uses them.
They are yes. Emails are being blocked due to the listing on spamrats.
Please show us a copy of one of the failure messages. Feel free to redact any private information, but please leave the IP addresses and reject messages visible. R's, John PS: In my experience, customers who think that their mail is being rejected due to a DNSBL we never heard of are almost always mistaken. A message bounces due to some random reason, they look up their IP on one of those bazillion DNSBL lookup pages, find some obscure DNSBL that lists them, and leap to the conclusion that's the problem.
On Thu, 10 Jan 2013, Julian DeMarchi wrote:
Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue.
That frequently just means they've subscribed to one of the monitoring services that notifies you if your IPs have turned up on any DNSBL the monitoring service has ever heard of, sometimes including ones that have been shut down, domain snatched up by speculators, and wildcard A record installed pointing at an ads landing page.
Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts.
If they're not mail servers, how is the DNSBL listing impacting them (assuming anyone even uses spamrats)? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 01/10/2013 01:30 PM, Jon Lewis wrote:
Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts.
If they're not mail servers, how is the DNSBL listing impacting them (assuming anyone even uses spamrats)?
Here[0] is the only message they give you. All mail servers have PTRs. At least one company uses spamrats. That's how it got escalated to me. --julian 0 - http://pastebin.com/dBSncSaV
On Wed, Jan 9, 2013 at 10:49 PM, Julian DeMarchi <julian@jdcomputers.com.au> wrote:
At least one company uses spamrats. That's how it got escalated to me.
Hi Julian, A couple of thoughts for you: 1. Spam Rats is a non-entity and anyone blocking email solely on Spam Rats' information is a fool. You can't be responsible for what every damn fool does on the Internet, so if the problem is that the customer sending small amounts of mail has run afoul of a single fool, you should consider limiting your efforts to helping the customer get in touch with that fool. 2. If the customer sending small amounts of email decides that blocking of multiple mail destinations is because of Spam Rats, they're almost certainly mistaken. Not about being blocked, but about the cause. Find out what's really going on. 3. If the customer is sending mail without a valid PTR record then they're probably on lists similar to rfc-ignorant as well. Check in to it. And help them fix the PTR record. 4. If the customer is sending enough email to find multiple folks relying on Spam Rats' information and they're doing it without having asked for valid PTR records, that's enough of a red flag that it's time for you to scrutinize just what email your customer is sending. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Jan 10, 2013 at 01:10:48PM +1000, Julian DeMarchi wrote:
On 01/10/2013 01:06 PM, Suresh Ramasubramanian wrote:
Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing?
Customers use the range. They had a complaint to us that the IP was listed by spamrats and thus the issue made it to my queue.
That said, it is best practice to set ptr records even for your unassigned ip space
Mail servers do need to have PTRs, but it is my _choice_ if my hosts that do not send mail have PTRs or not. I would not expect anyone to block my /24 for lack of PTRs on non-mail-sending hosts.
If you believe that BCP for your own servers is to have PTRs, are you giving the caveat to your customers that they shouldn't be running mail service without dealing with you for PTRs? Are you accepting their mail without these PTRs? :-) That bit of customer service philosophy aside, two obvious answers are wildcard (weak) or to hand the customers the keys to their own fate (best). Just delegate to them. Hopefully you are at least handing them addresses in clumps to make it less annoying on your zone files. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG
Once upon a time, Suresh Ramasubramanian <ops.lists@gmail.com> said:
That said, it is best practice to set ptr records even for your unassigned ip space
[citation needed] -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Personal experience is that I have had a large telco, which I won't name since they immediately unblocked, blocked exactly such a range once, for the exact same reason. RFCs and best practices often aren't a 100 % exact match so sorry, I can't dig up a cite. --srs (htc one x) On 10-Jan-2013 9:00 AM, "Chris Adams" <cmadams@hiwaay.net> wrote:
Once upon a time, Suresh Ramasubramanian <ops.lists@gmail.com> said:
That said, it is best practice to set ptr records even for your unassigned ip space
[citation needed] -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 1/9/2013 10:06 PM, Suresh Ramasubramanian wrote:
Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing?
That said, it is best practice to set ptr records even for your unassigned ip space
What label would you suggest be used for PTR records in unassigned space? If it is a standard best practice, why don't the RIRs do it for space that they have not yet assigned? Would this apply to IPv6 as well? -- Dave
Unused space generally gets a $generate type generic scripted runs which could be whatever, like ip-ad-dr-ess.example.com Not rid unallocated space, not that there's much of it in v4 As for v6 how popular do you see it getting for mail? On Thursday, January 10, 2013, Dave Sparro wrote:
On 1/9/2013 10:06 PM, Suresh Ramasubramanian wrote:
Who uses it? Or did you see your IP listed in one of those multiple dnsbl query sites and contacted them on general principles even though you didn't see any actual bounced email that could be traced to a spam rats listing?
That said, it is best practice to set ptr records even for your unassigned ip space
What label would you suggest be used for PTR records in unassigned space?
If it is a standard best practice, why don't the RIRs do it for space that they have not yet assigned? Would this apply to IPv6 as well?
-- Dave
-- --srs (iPad)
On 1/10/2013 9:53 AM, Suresh Ramasubramanian wrote:
Unused space generally gets a $generate type generic scripted runs which could be whatever, like ip-ad-dr-ess.example.com <http://ip-ad-dr-ess.example.com> If the IP address hasn't been assigned to example.com, why would make a DNS entry that implies that it has?
Not rid unallocated space, not that there's much of it in v4 Why not?
As for v6 how popular do you see it getting for mail? What does mail have to do with DNS policy for unassigned IP addresses?
On Thu, 2013-01-10 at 20:23 +0530, Suresh Ramasubramanian wrote:
Unused space generally gets a $generate type generic scripted runs which could be whatever, like ip-ad-dr-ess.example.com
Nothing that actually stores actual RRs will scale to the number of addresses available in IPv6. If you want a PTR for every possible address in your network, or even just every possible address in a single /64 subnet then you are SOL as far as IPv6 is concerned. The only way to do it is to fake it - for example by synthesising responses on the fly. You can't cache the synthesised responses either, that would be inviting a DoS. I said this would be "pointless" because if providing RRs were as simple as synthesising one on request, then the presence of a PTR record would no longer be a meaningful indicator of cluefulness (not that it is now IMHO, but opinions clearly differ on that).
As for v6 how popular do you see it getting for mail?
Well - at least as popular as IPv4 - eventually :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Mail is all this discussion is in the context of On Friday, January 11, 2013, Karl Auer wrote:
On Thu, 2013-01-10 at 20:23 +0530, Suresh Ramasubramanian wrote:
Unused space generally gets a $generate type generic scripted runs which could be whatever, like ip-ad-dr-ess.example.com
Nothing that actually stores actual RRs will scale to the number of addresses available in IPv6.
If you want a PTR for every possible address in your network, or even just every possible address in a single /64 subnet then you are SOL as far as IPv6 is concerned. The only way to do it is to fake it - for example by synthesising responses on the fly. You can't cache the synthesised responses either, that would be inviting a DoS.
I said this would be "pointless" because if providing RRs were as simple as synthesising one on request, then the presence of a PTR record would no longer be a meaningful indicator of cluefulness (not that it is now IMHO, but opinions clearly differ on that).
As for v6 how popular do you see it getting for mail?
Well - at least as popular as IPv4 - eventually :-)
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au <javascript:;>) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog
GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
-- --srs (iPad)
Mail is all this discussion is in the context of On Friday, January 11, 2013, Karl Auer wrote:
On Thu, 2013-01-10 at 20:23 +0530, Suresh Ramasubramanian wrote:
Unused space generally gets a $generate type generic scripted runs which could be whatever, like ip-ad-dr-ess.example.com
Nothing that actually stores actual RRs will scale to the number of addresses available in IPv6.
If you want a PTR for every possible address in your network, or even just every possible address in a single /64 subnet then you are SOL as far as IPv6 is concerned. The only way to do it is to fake it - for example by synthesising responses on the fly. You can't cache the synthesised responses either, that would be inviting a DoS.
I said this would be "pointless" because if providing RRs were as simple as synthesising one on request, then the presence of a PTR record would no longer be a meaningful indicator of cluefulness (not that it is now IMHO, but opinions clearly differ on that).
As for v6 how popular do you see it getting for mail?
Well - at least as popular as IPv4 - eventually :-)
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au <javascript:;>) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog
GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
-- --srs (iPad)
On Thu, Jan 10, 2013 at 3:45 PM, Dave Sparro <dsparro@gmail.com> wrote:
What label would you suggest be used for PTR records in unassigned space?
Some fixed string like "unassigned.<yourdomain>"? This would make it obvious that something is wrong if ever it leaks out. -- Matthias
I wouldn't flame you.. I think this forum lacks this kind of discussion. At least we can move on from the LinkedIn email saga earlier this week?
From my Galaxy Note II, please excuse any mistakes.
-------- Original message -------- From: Julian DeMarchi <julian@jdcomputers.com.au> Date: 01/09/2013 7:00 PM (GMT-08:00) To: NANOG <nanog@nanog.org> Subject: [SHAME] Spam Rats Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are "mass-listed" the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
We had issues and similar behavior from SORBS.net and TrendMicro ERS but have never dealt with Spam Rats. It was our second direct allocation from ARIN last year that was apart of a larger block that got split up. Our block was listed in their DUL. It was a pain to remove. They wanted our PTR records to say "static" and provide a longer TTL. Others on this list have shared similar stories. This is crazy but it's their service and seem to be a common practice amongst some RBLs. I hope you get your issue fixed. FYI - I have a PTR for all IPs. Just general practice. Otis -----Original Message----- From: Julian DeMarchi [mailto:julian@jdcomputers.com.au] Sent: Wednesday, January 09, 2013 8:59 PM To: NANOG Subject: [SHAME] Spam Rats Heya, I don't like to publicly shame[0] companies or services but today I have found a need too. There is an anti-spam company called Spam Rats[1]. They provide an RBL service and today is the first time I've seen them. So thank god they seem to not be used much. I'm emailing this list to advise of their listing pratices. They have listed a /24 of my companies for lack of PTRs in the range. Yes. Lack of PTRs in the /24 range. This is for co-lo customers. The range has a netural score on senderbase. This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer? Their removal process is also a joke. As we are "mass-listed" the normal removal process does not apply. I've used their contact form but doubt I'll get a response. Please make 2013 the year you migrate away from Spam Rats if you choose to use this service[2]. Regards, Julian 0 - is ready to get flamed. 1 - http://www.spamrats.com 2 - these are my opinions only
On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote:
FYI - I have a PTR for all IPs. Just general practice.
All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring them anyway. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
On 10/01/13 17:15, Karl Auer wrote:
FYI - I have a PTR for all IPs. Just general practice. All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring
On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: them anyway.
Regards, K.
$GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) I though the point of doing so was to establish with some degree of accuracy that there were 'real people' behind the administration of said IP, and that there was a somewhat increased level of accountability as a result - which suggests there is infact a point.
In message <50EE4113.2000906@blakjak.net>, Mark Foster writes:
On 10/01/13 17:15, Karl Auer wrote:
FYI - I have a PTR for all IPs. Just general practice. All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring
On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: them anyway.
Regards, K.
$GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.)
No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes.
I though the point of doing so was to establish with some degree of accuracy that there were 'real people' behind the administration of said IP, and that there was a somewhat increased level of accountability as a result - which suggests there is infact a point. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 1/9/2013 11:41 PM, Mark Andrews wrote:
$GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes.
Can you wildcard it? (Still an IPv6 implementation virgin, just curious :) ) Jeff
In message <50EE471C.7010409@utc.edu>, Jeff Kell writes:
On 1/9/2013 11:41 PM, Mark Andrews wrote:
$GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.) No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes.
Can you wildcard it?
No point. address -> name -> address doesn't work with wildcards.
(Still an IPv6 implementation virgin, just curious :) )
Jeff
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
No point. address -> name -> address doesn't work with wildcards.
(Still an IPv6 implementation virgin, just curious :) )
If you want to do generic IPv6 rDNS for all your hosts, you're stuck with a variety of less than great possibilities. One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.) Another is instrumenting the routers so that when they notice a new host on their network, they somehow send an update to the DNS servers to install rDNS for that host. If I had to guess, I would say that we'll eventually agree than on IPv6 networks, mail servers and other hosts who have reputations that matter will have fixed addresses assigned statically or via DHCP and rDNS, random client hosts won't. Teeth will gnash at how this makes some hosts second class and it violates the end to end principle, but tough noogies. R's, John
In message <20130110053429.55493.qmail@joyce.lan>, "John Levine" writes:
No point. address -> name -> address doesn't work with wildcards.
(Still an IPv6 implementation virgin, just curious :) )
If you want to do generic IPv6 rDNS for all your hosts, you're stuck with a variety of less than great possibilities.
One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.)
NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -1000000 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers.
Another is instrumenting the routers so that when they notice a new host on their network, they somehow send an update to the DNS servers to install rDNS for that host.
If I had to guess, I would say that we'll eventually agree than on IPv6 networks, mail servers and other hosts who have reputations that matter will have fixed addresses assigned statically or via DHCP and rDNS, random client hosts won't. Teeth will gnash at how this makes some hosts second class and it violates the end to end principle, but tough noogies.
R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.)
NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -1000000 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers.
I know, but figuring out on the fly what order the hashes are would be quite a coding feat. R's, John
In message <alpine.BSF.2.00.1301100106560.55043@joyce.lan>, "John R. Levine" wr ites:
One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.)
NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -1000000 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers.
I know, but figuring out on the fly what order the hashes are would be quite a coding feat.
subtract labels until you have one which fits the namespace pattern. that is the closest encloser <ce>. hash that name for the closest encloser. hash <label>.<ce> add/subtact one for the second half of the noqname proof. hash *.<ce> add/subtact one for the no wildcard proof.
R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
RE: PTRs for IPv6, see http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05 I've had many excellent suggestions for updates to it, which I intend to treat in the next couple of weeks. I don¹t cover PTRs for servers, because I don't see a scalability problem. However, I don't think I understand the conversation below. Pointers to make me smarter? Thanks, Lee On 1/10/13 1:22 AM, "Mark Andrews" <marka@isc.org> wrote:
In message <alpine.BSF.2.00.1301100106560.55043@joyce.lan>, "John R. Levine" wr ites:
One is a stunt rDNS server that synthesizes the records on demand. (Bonus points for doing DNSSEC, too. Double bonus points for doing NSEC3.)
NSEC3 is a waste of time in ip6.arpa or any similarly structured zone so -1000000 for doing NEC3 and effectively doing a DoS attack against yourself and the client resolvers.
I know, but figuring out on the fly what order the hashes are would be quite a coding feat.
subtract labels until you have one which fits the namespace pattern. that is the closest encloser <ce>. hash that name for the closest encloser. hash <label>.<ce> add/subtact one for the second half of the noqname proof. hash *.<ce> add/subtact one for the no wildcard proof.
R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Subject: Re: [SHAME] Spam Rats Date: Thu, Jan 10, 2013 at 03:50:37PM +1100 Quoting Mark Andrews (marka@isc.org):
In message <50EE471C.7010409@utc.edu>, Jeff Kell writes:
Can you wildcard it?
No point. address -> name -> address doesn't work with wildcards.
OTOH, if the requirement is "must have PTR" and/or "organisation fwd domain name should show up in PTR RDATA" then wildcards have a place. And yes, BIND loads and answers, as expected. *.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se. ...will work just fine, for instance. I did it for a 200+ segment LAN party, couple years ago. And as is usual with wildcards, if you do need to insert a real record, it will take over just as expected. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ...
*.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se.
...will work just fine, for instance.
Since there is no AAAA record for a.node.on.vlan344.namn.se., this won't work fine in any rDNS check I'm aware of. You are aware that useful rDNS has to have matching forward DNs, right?
Date: 10 Jan 2013 20:57:25 -0000 From: "John Levine" <johnl@iecc.com> Subject: Re: [SHAME] Spam Rats
*.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se.
...will work just fine, for instance.
Since there is no AAAA record for a.node.on.vlan344.namn.se., this won't work fine in any rDNS check I'm aware of.
it works just fine, as long as there is one AAAA for that name (even in a different netblock), and -that- adderess has rDNS matching the AAAA
You are aware that useful rDNS has to have matching forward DNs, right?
"Not exactly." <grin> The 'usual' test is 'rev->fwd-rev' and compare the results of the two 'rev' look-ups. This allows a host with multiple interfaces to have -one- name for all interfaces.
John Levine <johnl@iecc.com> wrote:
*.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se. ...will work just fine, for instance.
Since there is no AAAA record for a.node.on.vlan344.namn.se., this won't work fine in any rDNS check I'm aware of.
I believe it's relatively common for mail servers to just check the existence of a PTR record without any further sanity checking, e.g. Postfix's reject_unknown_reverse_client_hostname smtpd_client_restrictions option. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
On 10 Jan 2013, at 6:41 AM, Mark Andrews <marka@isc.org> wrote:
No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you had machines that supported zettabytes of data the zone would never load in human lifetimes.
Because hitting things in memory is the only way we can ever respond to a data request. This wording is about as excellent as those who've been quoted on record to say people wouldn't want TVs ("boxes of wood") in their living rooms, etc. -J
On Jan 9, 2013, at 20:18 , Mark Foster <blakjak@blakjak.net> wrote:
On 10/01/13 17:15, Karl Auer wrote:
FYI - I have a PTR for all IPs. Just general practice. All IPs actually in use, or all possible IPs in a network? If the latter, then it's not gunna fly for IPv6. Not at all. Not unless you synthesise the responses - in which case there is no point to requiring
On Wed, 2013-01-09 at 21:14 -0600, Otis L. Surratt, Jr. wrote: them anyway.
Regards, K.
$GENERATE, as someone else pointed out, solves that problem for you? (Does it scale for IPv6? I can't recall - but surely this could be scripted too.)
Mental exercise... $GENERATE is a run-time macro which is parsed to create in-memory PTR records for all included entries. The end result in memory is identical to having typed in all of the PTR records in a zone file. If you're running a 64 bit architecture, you can, theoretically, address a 64-bit memory space. However, that would require each in-memory PTR record to fit in 1 byte and you would have no room remaining for little silly inconsequential things like forward zones, the DNS server software, the operating system, the network stack, etc. This assumes, of course, that you have maxed out your RAM to a full 18,000+ petabytes (which I tend to doubt). If not, then, you don;t even have enough RAM for 1 byte per PTR record. I know PTR records can theoretically be pretty compressible, but I doubt you can get below 1 byte/record even with the best of compression algorithms. Real time synthesis (synthesis on request) according to something similar to $GENERATE might be feasible, but $GENERATE as implemented does not scale to IPv6.
I though the point of doing so was to establish with some degree of accuracy that there were 'real people' behind the administration of said IP, and that there was a somewhat increased level of accountability as a result - which suggests there is infact a point.
I'll leave the flaws in that theory as an exercise to the reader. Owen
On Jan 9, 2013, at 8:58 PM, Julian DeMarchi wrote:
This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer?
We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well. I tried SpamRats a few years ago, but found them to have too many false positives. Then, they were trying to be early detectors of spam orginiating from static IP cable/DSL customers. Good idea, but poorly executed in operation. --Chris
On 01/10/2013 01:27 PM, Chris Boyd wrote:
We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well.
This is the normal pratice. I would never run a mail server without a PTR. --julian
On Wed, Jan 09, 2013 at 09:27:17PM -0600, Chris Boyd wrote:
We're small shop, but our policy is not to accept email from addresses without PTRs. And we have a long list of pool/dhcp/dyn/resnet PTRs we don't accept mail from as well.
This is (and has been) a best practice for most of a decade, ever since the rise of the zombies. Real mail servers have matching A and PTR records, and real (i.e., non-generic) FQDN hostnames. They also HELO/EHLO with real, non-generic FQDN hostnames that resolve, and which (preferably) match that in the A record. Everything else is at best suspect and probably either (a) a zombie or (b) incompetently run. Thus -- and these are examples seen in a local spamtrap in the last few hours -- none of these should be permitted to even *attempt* to deliver mail to real live addresses: 2.132.135.33 (no rdns) 37.44.121.227 (no rdns) 41.97.154.184 (no rdns) 41.191.104.24 (no rdns) 46.177.235.253 ppp046177235253.access.hol.gr 60.254.50.150 50.254.60.150.hathway.com 64.25.225.52 (no rdns) 74.7.101.50 (no rdns) 77.126.116.112 (no rdns) 79.180.105.90 bzq-79-180-105-90.red.bezeqint.net 80.232.221.197 (no rdns) 81.248.60.11 lcayenne-151-5-11.w81-248.abo.wanadoo.fr 85.30.103.215 (no rdns) 88.77.212.175 dslb-088-077-212-175.pools.arcor-ip.net 89.223.2.149 ip-149.2.223.89.net.unnet.ru 93.86.110.126 93-86-110-126.dynamic.isp.telekom.rs 95.140.197.66 host-95-140-197-66.customers.adc.am 110.49.235.132 (no rdns) 117.6.200.103 (no rdns) 117.212.210.190 (no rdns) 120.61.90.56 triband-mum-120.61.90.56.mtnl.net.in 122.163.226.123 abts-north-dynamic-123.226.163.122.airtelbroadband.in 122.166.232.127 abts-kk-static-127.232.166.122.airtelbroadband.in 123.24.97.69 dynamic.vdc.vn 123.24.198.246 (no rdns) 178.126.109.101 (no rdns) 190.66.167.111 (no rdns) 195.128.253.152 ip253-152.dl.uz.ua 200.56.5.180 200-56-5-180.dynamic.axtel.net 200.67.199.254 dsl-200-67-199-254-sta.prod-empresarial.com.mx 201.230.49.12 client-201.230.49.12.speedy.net.pe 206.55.180.8 (no rdns) 213.175.137.146 (no rdns) 220.227.74.69 (no rdns) 222.124.11.26 26.subnet222-124-11.astinet.telkom.net.id 222.253.178.173 localhost ---rsk
On Thu, Jan 10, 2013 at 12:58:59PM +1000, Julian DeMarchi wrote:
This is the first RBL I have seen list a /24 for lack of PTRs. Not for sending spam, but just PTRs alone. How do you explain this to your customer?
First, this would be better on mailop. Second, they're running a DNSBL, not *the* RBL. Third, anyone may run any DNSBL with any policy they wish: listing IP addresses whose octets are primes, domains with the letter "j" in their names, etc. Provide they comply with RFC 6471, this isn't a problem. What *might* be a problem is how they're used and by whom, but one of the nice features of DNSLs in operational practice is that those with suboptimal listing policies aren't used much. Fourth, one of the hundreds of DNSBLs may be the least of your problems. For roughly a decade now, it's been a very good idea to refuse/defer all mail traffic from anything which doesn't have matching PTR and A records. (The refuse/defer depends on whether the problem appears to be a permanent misconfiguration or the temporary consequence of a DNS oops.) But again: mailop would be better for this. ---rsk
ARGH, ok, enough with: They can have any policy they like, it's their equipment and no one is being forced to use them. That's tacit, I'd hope. Doesn't mean people can't do dopey things well within their rights and maybe sounding it out would give them some clue, or at least warn others to stay away, tho I'd agree NANOG is probably not the right venue. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Thu, Jan 10, 2013 at 12:58:59PM +1000, Julian DeMarchi wrote:
This is the first RBL I have seen list a /24 for lack of PTRs.
Maybe because it's redundant: a PTR check should be automatic on any incoming SMTP connection. Just think of all the traffic their survey tool generated in compiling this totally useless list. The humanity! Nicolai
On 1/9/2013 9:58 PM, Julian DeMarchi wrote:
There is an anti-spam company called Spam Rats[1].... They have listed a /24 of my companies for lack of PTRs in the range
I find SpamRats' lists helpful in spam filtering as a low scoring list because it puts some new emitters which haven't had time to build up bad reputation "over the top". Having said that, they actually have 3 lists, and only one of those 3 lists involves listing IPs ONLY based on "no PTR". They also have an "all" list, but they document on their web site how to query the "all" list, but then ignore those return codes indicating the "no PTR" list. That is how I use them because I didn't need their "no PTR" list since it would be redundant for me since I was already checking for "no PTR" myself... and I didn't want to score twice on that one attribute. But if your information is accurate and I understand you correctly, then I agree that they shouldn't list the whole /24 in their PTR list if SOME of those IPs *do* have PTRs. (Actually, I wasn't aware that any of their lists involved /24 blocks. They should probably be more clear about that on their web site.) On their web site, on the http://www.spamrats.com/about.php page, under the heading, "NEW - SpamRats All", they describe this method of querying their "all" list, but ignoring their PTR list's particular return code. I think they made THAT suggestion FOR VERY GOOD REASON. Therefore, you could use this to your advantage by going back to whichever recipient blocked your mail and say... "hey, you're NOT using spamRATS in a manner that they suggested", then point them to the section I referenced and explain that many don't use their "no PTR" list since most spam filters already do that. Maybe that could be a short term solution for you? (probably better than nothing) -- Rob McEwen http://dnsbl.invaluement.com/ rob@invaluement.com +1 (478) 475-9032
On 01/10/2013 02:55 PM, Rob McEwen wrote:
But if your information is accurate and I understand you correctly, then I agree that they shouldn't list the whole /24 in their PTR list if SOME of those IPs *do* have PTRs.
My information is correct. The /24 is listed _only_ on the no-ptr list. --- List Status RATS-Dyna - Not on the list RATS-NoPtr - On the list. Worst Offender Alert RATS-Spam - Not on the list --- --julian
participants (28)
-
Barry Shein -
Chris Adams -
Chris Boyd -
Dave Sparro -
Jeff Kell -
Jima -
Joe Provo -
John Levine -
John R. Levine
-
Jon Lewis -
JP Viljoen -
Julian DeMarchi -
Karl Auer -
Lee Howard -
Mark Andrews -
Mark Foster -
Matthias Leisi -
Måns Nilsson -
Nicolai -
Otis L. Surratt, Jr. -
Owen DeLong -
Rich Kulawiec -
Rob McEwen -
Robert Bonomi -
Suresh Ramasubramanian -
Tony Finch -
Warren Bailey -
William Herrin