Jump to content

DNS Issues


jefft

Recommended Posts

Wazoo, please see my rant about SSW, TCP, UDP, and Akamai at http://forum.spamcop.net/forums/index.php?...1411entry1411

Yep, that rings a bell, but as I said, I was elswhere at the time I ran with what I had available. On the other hand, one can't blame SSforWin for the interesting line cesmail.net A (Address) 0.0.0.0 ... but that's another story <g>

Link to comment
Share on other sites

Jeff,

I'm using Windows XP and Microsoft Outlook. My outlook account was set to retrieve e-mail from spamcop. It was working fine until this morning. I reviewed the link you posted. My account is set up properly as far as I can tell. Is there a way to change the way my outlook retrieves the mail from spamcop that is EASY?

Thanks.

Nancy

Link to comment
Share on other sites

WRT the remaining DNS issues for the MX values for "cesmail.net" -- visit these two URLs:

http://www.dnsstuff.com/tools/ptr.ch?ip=216.154.195.36

http://www.dnsstuff.com/tools/ptr.ch?ip=216.154.195.53

The first is for the IP address for mx.cesmail.net, and the second for mx2.cesmail.net. Unfortunately, the second one is currently producing a serious error, which is the lack of PTR records -- here's what the tool reports:

Answer:

No PTR records exist for 216.154.195.53. [Neg TTL=1800 seconds]

Details:

ns4.edeltacom.com. (an authoritative nameserver for 195.154.216.in-addr.arpa., which is in charge of the reverse DNS for 216.154.195.53)

says that there are no PTR records for 216.154.195.53.

The domain "edeltacom.com" is where the mail servers are hosted, so to me, it looks like the "ns4.edeltacom.com" isn't quite properly configured (although I admit to not really knowing that much about DNS...but I can run a tool and see errors).

Speaking of errors....the tool at "squish.net" that JT referred to is also producing errrors for both of the MX entries for cesmail.net.

DT

19871[/snapback]

How is this adversely affecting your or anybody's email?

Technically, according to Internet Standard #13, RFC 1034 entitled "Domain names - concepts and facilities", Section "3.3. Technical guidelines on use" states "Because we need a reliable inverse mapping from address to host name, a special mapping for addresses into the IN-ADDR.ARPA domain is also defined" and RFC 1035 entitled "Domain names - implementation and specification", Section "3.5. IN-ADDR.ARPA domain" states "The intent of this domain is to provide a guaranteed method to perform host address to host name mapping". enocsupport at edeltacom.com should honor that need and guarantee.

Link to comment
Share on other sites

Jeff,

I'm using Windows XP and Microsoft Outlook.  My outlook account was set to retrieve e-mail from spamcop.  It was working fine until this morning.  I reviewed the link you posted.  My account is set up properly as far as I can tell.  Is there a way to change the way my outlook retrieves the mail from spamcop that is EASY?

Thanks.

Nancy

19878[/snapback]

Nancy,

If your Outlook or Outlook Express is supposed to be removing the mail from your SpamCop Email System account when it downloads it, you should be able to easily change the name of the mailserver you are using to do that - in Outlook or Outlook Express, please do the following:

  • Select the "Tools" Menu.
  • Select the "Accounts" Menu Item.
  • Select the "Mail" Tab.
  • Select the appropriate Account.
  • Click the "Properties" button.
  • Click the "Servers" Tab.
  • In the "Server Information" Section, change the Server Name to the right of "Incoming mail (POP3):" to "216.154.195.50" without quotes.
  • Click the "OK" Button.
  • Click the "CLOSE" Button.
  • Try to retrieve your email again.
  • In a few days, when people stop complaining about missing SpamCop email, change that Server Name back to "pop.spamcop.net" without quotes.

Link to comment
Share on other sites

Jeff,

Thank you so much for your patience with me!  I appreciate the help!  I did what you said, and it seemed to work.

Nancy :D

19896[/snapback]

Nancy,

You're welcome. Glad I could help.

Link to comment
Share on other sites

This morning when I tried to retrieve e-mail, I received the following message:

The Server could not be found. (Account: 'mail.comcast.net', pop3 server:'mail.spamcop.net', Error Number:0x800ccc0d).

Is this a problem with my ISP or Spamcop?

Thanks.

Nancy

19849[/snapback]

Well, I really don't know anything about this stuff but FWIW, I think we're having the same problem which would indicate that it's probably Spamcop.

I can see my e-mails in the Spamcop system using an internet browser but when I try to download those e-mails to my hard drive (Mac 0S10.3.5) using Eudora 6.1, I get an error message that says that the domain name does not exist.

Could someone who knows more about this than we do, just confirm that what Nancy and I are experiencing is related to this DNS thing with Spamcop? I'm using mail.spamcop.net in my Eudora settings. Is there a different mail server that I could try pointing Eudora to?

Thanks!

Jude

Link to comment
Share on other sites

I'm using mail.spamcop.net in my Eudora settings.  Is there a different mail server that I could try pointing Eudora to?

19940[/snapback]

Yes, all of the following should work at present to access that Server, but some may not work for you for the next few days:

pop.spamcop.net (this is the "right" one for POP3)

imap.spamcop.net (this is the "right" one for IMAP4)

mail.spamcop.net (provides limited HTTP support)

216.154.195.50 (if all else fails)

pop.cesmail.net (backup for POP3)

imap.cesmail.net (backup for IMAP4)

mail.cesmail.net (backup for HTTP)

Link to comment
Share on other sites

From an MS-DOS prompt on a Windows box;

C:\>tracert mail.spamcop.net

Unable to resolve target system name mail.spamcop.net.

From a Terminal screen, OS-X on an iBook;

wazoo% traceroute mail.spamcop.net

traceroute to mail.cesmail.net (216.154.195.50) ...

(That's not a typo and it's also timing out .....hmmmm)

Windows box;

Tracing route to pop.spamcop.net [216.154.195.50]

16 103 ms 100 ms 100 ms suw02.gig5-0.edeltacom.com [66.35.174.150]

17 99 ms 102 ms 112 ms suwC1-gig3-5.edeltacom.com [216.154.207.13]

18 100 ms 100 ms 100 ms suwE1N-gig1-1-4.edeltacom.com [216.154.207.22]

19 100 ms 100 ms 100 ms pop.spamcop.net [216.154.195.50]

C:\>tracert mx.cesmail.net

Unable to resolve target system name mx.cesmail.net.

C:\>tracert cesmail.net

Unable to resolve target system name cesmail.net.

C:\>tracert mailgate.cesmail.net

Tracing route to mailgate.cesmail.net [216.154.195.36]

16 108 ms 107 ms 118 ms suw02.gig5-0.edeltacom.com [66.35.174.150]

17 101 ms 102 ms 100 ms suwC1-gig3-5.edeltacom.com [216.154.207.13]

18 117 ms 101 ms 102 ms suwE1N-gig1-1-4.edeltacom.com [216.154.207.22]

19 99 ms 102 ms 102 ms mailgate.cesmail.net [216.154.195.36]

OS-X box;

wazoo% nslookup mx.cesmail.net

Non-authoritative answer;

Name: mx.cesmail.net

Addresses: 216.154.195.36, 216.154.195.53

C:\>tracert 216.154.195.36

Tracing route to mailgate.cesmail.net [216.154.195.36]

16 100 ms 100 ms 100 ms suw02.gig5-0.edeltacom.com [66.35.174.150]

17 100 ms 103 ms 101 ms suwC1-gig3-5.edeltacom.com [216.154.207.13]

18 101 ms 102 ms 101 ms suwE1N-gig1-1-4.edeltacom.com [216.154.207.22]

19 101 ms 100 ms 100 ms mailgate.cesmail.net [216.154.195.36]

C:\>tracert 216.154.195.53

Tracing route to 216.154.195.53 over a maximum of 30 hops

16 99 ms 99 ms 100 ms suw02.gig5-0.edeltacom.com [66.35.174.150]

17 99 ms 121 ms 102 ms suwC1-gig3-5.edeltacom.com [216.154.207.13]

18 100 ms 101 ms 126 ms suwE1N-gig1-1-4.edeltacom.com [216.154.207.22]

19 99 ms 99 ms 103 ms 216.154.195.53

(notice the lack of any name assignment there)

wazoo% nslookup 216.154.195.53

**** can't find 216.154.195.53: Non-existent host/domain

wazoo% nslookup 216.154.195.36

Name: mailgate.cesmail.net

Address: 216.154.195.36

Eye are glazing over at this point .... consider this yet more data points ....

Link to comment
Share on other sites

Please try using the following syntax for nslookup to specify the nameserver.

C:\>nslookup mx.cesmail.net ns6.zoneedit.co.uk

Server:  ns6.zoneedit.co.uk

Address:  217.160.131.209

Name:    mx.cesmail.net

Addresses:  216.154.195.53, 216.154.195.36

Link to comment
Share on other sites

As I'd pointed out earlier (somewhere) the second 'variable' in that string tells the command to use that specific server, which in this case is the DNS host .... what's at issue for the folks having problems still goes back to propagation. The rest of that last post was again a bit of stuff relating to the fact that there are still some other issues "out there" ... as stated, the lack of a "name" showing up for 216.154.195.53 for instance ....

admitting that I had started looking something up, ended up with three active keybaords and the laptop, and actually forgot what started the mess. Posted data as set points and also a bit of a demo for others to try to see if they got different / better results ... yeah, that's it, back to others asking about "their" connection ...

Link to comment
Share on other sites

I'm having a wierd problem that, so far, nobody else has reported:

From home, via RoadRunner, I can hit webmail.spamcop.net, but my email program (Mail.app on OS X) can't see the IMAP server.

But - and here's the wierd part - both webmail and IMAP mail are working fine from school... where we use RoadRunner! It's the same system and ISP, since I use a PowerBook.

:blink:

Link to comment
Share on other sites

sdimbert, RoadRunner has lots of name servers. It wouldn't surprise me that Mail.app on OS X at your home would be having trouble using its configured IMAP Server because your home is using a different name server than your school. Please try to reconfigure Mail.app to use other names or perhap the IP Address of the SpamCop IMAP Server as specified in my Post #34 above until it works. Thanks!

Link to comment
Share on other sites

Is the problem with Akami, nameservices, or somewhere else? Seems to me it would be good to know that first given their good history so far.

19822[/snapback]

The problem was at eNom's name-services.com, and was compounded by dependencies on name-services at Corporate Email Services.
Link to comment
Share on other sites

Of course I read it. It was not clear to me.

Wow! ... it took a while, but finally figured ou that this was a response to an item posted over 24 hours ago ....

Did you actually read JT's explanation?  It was the Julian/Ironport side of the house that went the big-buck route with Akamai.

19836[/snapback]

And the situation is this. Question posed - was this DNS issue an Akamai problem?

JT's explanatory post clearly stated that Julian's side of the house went with Akamai, JT's side of the house did not. So I'm not sure why the answer to the question asked isn't clear at this point.

Link to comment
Share on other sites

JeffT,

I really appreciate your posting this information. I have a customer that has been getting random bounce messages for 2 days now, and I've been going mad. :rolleyes: While the problem had nothing to do with SpamCop, this is the only place I've found mention of the problem with name-services.com. That is ultimately where their e-mail resolves. Can you point me to an explanation closer to the source, so I can document the problem?

Thanks, in advance,

JeffGoneMad

Link to comment
Share on other sites

JeffT,

I really appreciate your posting this information.  I have a customer that has been getting random bounce messages for 2 days now, and I've been going mad.  :rolleyes:  While the problem had nothing to do with SpamCop, this is the only place I've found mention of the problem with name-services.com.  That is ultimately where their e-mail resolves.  Can you point me to an explanation closer to the source, so I can document the problem?

Thanks, in advance,

JeffGoneMad

20009[/snapback]

Sorry, I don't have much of an explanation. All evidence suggests that name-service.com has been returning incorrect information occasionally. I don't know if this is just a random thing or dependent on some particular specifics. I sent them a note and got a clueless response. The problem was going to be convincing them that 0.001% of their answers were wrong or something. In the end, we just changed to a company with more clue.

JT

Link to comment
Share on other sites

To my shock, name-service.com actually responded to my query stating that they know what the problem was and that they've fixed it.

First, we've never had a A record for the cesmail.net or cqmail.net names by themselves. That means you couldn't go to http://cesmail.net or look up its IP address. There was never any need to. Names like pop.cesmail.net exist and cesmail.net by itself has an MX record. That has worked for years.

Apparently last weekend, name-service.com rolled out a change which changed their response when asked for that A record. Previously, they would return an SOA record. In the new software, they no longer did. By itself, that doesn't sound like an error to me, but I don't know exactly what the old and new responses looked like.

The problem, according to them, is that some old BIND servers started saying that the domain didn't exist if it did a query and didn't get the SOA back. This might explain why we could never see any bad data being returned, but people were having problems nonetheless. It's a pretty specific combination of factors needed to see the problem.

Name-service.com says they got complaints from lots of people, not just about our domain but about many domains. They reverted the change they made earlier so they believe they've fixed it on their end. That's pretty much moot because we've stopped using them, but it's nice to know.

I'm not 100% convinced that this explanation explains everything we were seeing. However, at least they've acknowledged that there was a change on their end, that change caused problems, and they've reverted it.

JT

Link to comment
Share on other sites

JT, some of us are concerned about the remaining red flag at http://www.dnsreport.com/tools/dnsreport.c...ain=cesmail.net :

FAIL

Duplicate MX records

WARNING: You have duplicate MX records. This means that mailservers may try delivering mail to the same IP more than once. Although technically valid, this is very confusing, and wastes resources. The duplicate MX records are:

mx.cesmail.net. and mx2.cesmail.net. both resolve to 216.154.195.36.

I'm guessing that your rationalization for those duplicate A records for the cesmail.net mailservers is that they are for redundancy and/or load distribution. However, if the first mailserver name chosen is down but the other mailserver is up, with this configuration there is a 50% chance (or possibly 100% if the sender's resolver doesn't randomize) that the second one chosen will also be down, whereas if each mailserver name had only one IP Address, that chance would go down to 0%. OTOH, with both mailservers up the vast majority of the time, there is a strong argument for load distribution. A couple of alternative scenarios for reducing normal load would be: have a more powerful primary mailserver; or have two or more mailservers hiding behind one IP Address and load-balancing hardware.

Link to comment
Share on other sites

JT, some of us are concerned about the remaining red flag at http://www.dnsreport.com/tools/dnsreport.c...ain=cesmail.net :

I'm guessing that your rationalization for those duplicate A records for the cesmail.net mailservers is that they are for redundancy and/or load distribution.  However, if the first mailserver name chosen is down but the other mailserver is up, with this configuration there is a 50% chance (or possibly 100% if the sender's resolver doesn't randomize) that the second one chosen will also be down, whereas if each mailserver name had only one IP Address, that chance would go down to 0%.  OTOH, with both mailservers up the vast majority of the time, there is a strong argument for load distribution.  A couple of alternative scenarios for reducing normal load would be: have a more powerful primary mailserver; or have two or more mailservers hiding behind one IP Address and load-balancing hardware.

20095[/snapback]

Yes, I know all about that stuff. Having a more powerful mail server isn't an answer. Even the most powerful machine out there can crash.

While the dnsreport.com text makes a big deal about it, it really isn't a problem. The incoming mail servers have been extremely reliable. So, the DNS gives us basic load balancing. If a mail server were to crash, we'd have a poor man's redundancy. I do have plans for a more sophisticated setup, but with the new SpamAssassin setup taking so many resources, it wasn't clear exactly what we should do with those incoming machines.

I don't want to sound cocky, but the problems are probably more complicated than they appear from the outside. We've got it under control, though.

JT

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...