June 3 2011 Friday
Domino and semaphore errors - the fix you would never believe (I didn’t)
So a curious set of events sent a Domino 8.5.2 upgrade a bit pear shaped before my departure to UKLUG. This was an AS400 with Domino 8.5.1 FP3 and was taken to 8.5.2 FP2. Additionally we were adding in a Lotus Protector for Mail Encryption server into the mix too.
Here in lies the issue. See the customer routes all mail to Message Labs and had that set in the server config document as something like:
So we added in the LMPE server (let's say at address 192.168.0.237) and therefore changed the config document to:
So we're good right? That's what I though too. 12 hours later the Domino server comes to a screeching halt and NSDs. Several times. Uh-oh. We double check everything and see tons of semaphore errors on the Domino console (never good by the way) and tons of DNS MX look-up errors. The error was similar to this:
With no apparent fix on the horizon we called support. It turned out that this server had a faulty DNS which was really the root cause. Now this customer doesn't use DNS (don't ask) hence the issue. So what is the fix? Square brackets! (Why Domino insists on still using DNS for an IP address is a whole different question)
The other potential fix "could" be to set this field to "Local Lookup Only" but we were unsure of any other issues that may arise so we stuck with square brackets:
Moral of the story. When adding IP addresses to server config docs always use square brackets on IP addresses (not domain names, just IPs). Even if the help text doesn't mention it. I hope this saves someone from the stomach turning sight of a perfectly good server from NSDing out the wazoo.
Here in lies the issue. See the customer routes all mail to Message Labs and had that set in the server config document as something like:
So we added in the LMPE server (let's say at address 192.168.0.237) and therefore changed the config document to:
So we're good right? That's what I though too. 12 hours later the Domino server comes to a screeching halt and NSDs. Several times. Uh-oh. We double check everything and see tons of semaphore errors on the Domino console (never good by the way) and tons of DNS MX look-up errors. The error was similar to this:
Router: DNS server returned an error searching for MX records. The destination domain may not exist: 192.168.0.237, Error: Non-existent domain(NXDOMAIN)
With no apparent fix on the horizon we called support. It turned out that this server had a faulty DNS which was really the root cause. Now this customer doesn't use DNS (don't ask) hence the issue. So what is the fix? Square brackets! (Why Domino insists on still using DNS for an IP address is a whole different question)
The other potential fix "could" be to set this field to "Local Lookup Only" but we were unsure of any other issues that may arise so we stuck with square brackets:
Moral of the story. When adding IP addresses to server config docs always use square brackets on IP addresses (not domain names, just IPs). Even if the help text doesn't mention it. I hope this saves someone from the stomach turning sight of a perfectly good server from NSDing out the wazoo.
Discussion for this entry is now closed.
Comments (3)
This has been an issue for years (i.e. many versions) with Foreign SMTP domain documents routing to a relay server. Same fix, square brackets.
Moreover, If you want to use 2 ip addresses to make a SMTP failover and you don't want to see "Router: DNS server returned an error searching for MX records. The destination domain may not exist: 192.168.0.237, Error: Non-existent domain(NXDOMAIN)" on the Domino console, you must add a second bracket to the first IP address. If not, only the second one is used to make relay SMTP:
[[192.168.0.237],[192.168.0.238]
Ah, yes. Been cooked by that as well.
192.168.111.111 LOOKS like an IP address to you, but... in a domino config, it's just a very strange host name.
Ah, yes, [192.168.111.111], now THAT's an ip address.