Jump to content

Reverse lookup anti-spam


mrmaxx

Recommended Posts

Had a problem at work here for about a half hour where I couldn't send emails outside of the company because our domain name was not able to be resolved. I even tried looking us up at SpamCop by putting in the domain name of the company (which shall remain nameless) in the spam reporting window. As a result, all my emails outside the company and incoming from outside bounced.

That got me to wondering about the whole DNS-based anti-spam system. Did anyone envision what would happen if a sender's DNS got FUBARed somehow so that the domain name of the sender was no longer resolveable? The practical effect seems to be that the sender's email gets rejected by the receiving server, which, to me, would not necessarily be the best practice.

That being said, I've always said that email was never designed to be a guaranteed message delivery system, despite all the add-ons such as delivery confirmation or "read receipts" etc.

Link to comment
Share on other sites

Don't know a lot about it but the DNS resolution system seems pretty robust. There might occasionally be problems down the line, with ISP-provided nameservers briefly glitching which might affect outgoing mail or internet access generally and that can be seen when, for instance, a Windows nslookup from a local machine on a domain name comes back with "Non existent domain" but repeat with a public name server, such as 8.8.8.8 for Google and the correct "A" record is obtained. Your router(s) can be temporarily assigned a public resolver in such a case.

Never encountered your problem personally where it is your domain that won't resolve - though I have seen it happening a few times. Robtex will show a lot about a domain and could be a useful monitor of the status - and recovering DNS can be virtually "seen" coming back on line little by little (and I suppose the earlier falling off line as caches expire similarly) through repeated scans with a service like just-ping.com (actually gone but taken up through cloudmonitor.ca.com and just-ping.com re-directs there these days).

None of which directly addresses your concerns but at the back of my mind is the thought that the "robustness" of the resolution system has heretofore not required any consequent accommodation for its systemic failure. General failure means the end of the internet after all. Or perhaps total reliance on IPv6 which might be the same thing at this stage. A half-hour's downtime here and there for the occasional domain in exceptional circumstances doesn't rate as a real problem, I guess.

Or, I might be totally confused.

And I think your increased problems after checking your domain through the SC parser might have just been so-incidence, AFAIK checking an isolated URI/IP address/e-mail address through the parser submission form can have no consequence for the entity checked. I suppose SC might have some bogon filtering in place to avoid abuse of resources, if so that should only affect the use of the tool and temporary DNS record loss (of indeterminate extent across the internet) should not automatically/instantly make associated IP addresses into bogons. But I'm just supposing.

Link to comment
Share on other sites

Don't know a lot about it but the DNS resolution system seems pretty robust. There might occasionally be problems down the line, with ISP-provided nameservers briefly glitching which might affect outgoing mail or internet access generally and that can be seen when, for instance, a Windows nslookup from a local machine on a domain name comes back with "Non existent domain" but repeat with a public name server, such as 8.8.8.8 for Google and the correct "A" record is obtained. Your router(s) can be temporarily assigned a public resolver in such a case.

Never encountered your problem personally where it is your domain that won't resolve - though I have seen it happening a few times. Robtex will show a lot about a domain and could be a useful monitor of the status - and recovering DNS can be virtually "seen" coming back on line little by little (and I suppose the earlier falling off line as caches expire similarly) through repeated scans with a service like just-ping.com (actually gone but taken up through cloudmonitor.ca.com and just-ping.com re-directs there these days).

None of which directly addresses your concerns but at the back of my mind is the thought that the "robustness" of the resolution system has heretofore not required any consequent accommodation for its systemic failure. General failure means the end of the internet after all. Or perhaps total reliance on IPv6 which might be the same thing at this stage. A half-hour's downtime here and there for the occasional domain in exceptional circumstances doesn't rate as a real problem, I guess.

Or, I might be totally confused.

And I think your increased problems after checking your domain through the SC parser might have just been so-incidence, AFAIK checking an isolated URI/IP address/e-mail address through the parser submission form can have no consequence for the entity checked. I suppose SC might have some bogon filtering in place to avoid abuse of resources, if so that should only affect the use of the tool and temporary DNS record loss (of indeterminate extent across the internet) should not automatically/instantly make associated IP addresses into bogons. But I'm just supposing.

Well, I work for the ISP. :D Our external DNS servers were down for about 20-30 minutes due to a glitch. They said they had migrated to new external servers last night and then tried to sync everything back up afterward so the TTL would be correct and for some reason it failed. So they had to do a restore and I'm guessing that took most of the 20-30 minutes. :(

BTW, I wasn't concerned about SpamCop not resolving the domain name, per se. Just using it to illustrate the point that it was totally non-resolvable.

Link to comment
Share on other sites

Well, I work for the ISP. :D Our external DNS servers were down for about 20-30 minutes due to a glitch. They said they had migrated to new external servers last night and then tried to sync everything back up afterward so the TTL would be correct and for some reason it failed. So they had to do a restore and I'm guessing that took most of the 20-30 minutes. :(

Ah, you'd be praying for IPv6 then :P
BTW, I wasn't concerned about SpamCop not resolving the domain name, per se. Just using it to illustrate the point that it was totally non-resolvable.

Ah, I probably read your post a little too literally. Anyway sort of surprised a cached result wasn't used - but I guess those are keyed to IP addresses/ranges and if an IP range can't be determined through DNS the dummy spit is immediate.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...