Novell GroupWise 7 Administrator Solutions Guide
| Now before you do anything to your own GroupWise environment, we need to take a much closer look at the relation between the DNS and your GWIAs. Understanding Why GWIA Needs to Have Access to a Stable and Fast DNS
When you start your GWIA, the first thing it will do is test the DNS connection. It will actually try to perform a DNS lookup for the domain novell.com and will show the normal GWIA console screen if this attempt succeeds. When troubleshooting problems with the GWIA, we've often found that problems with the DNS were involved. Tip If during the startup of the GWIA the blue and almost-blank startup screen stays up for a few seconds or more, you might want to check your DNS. A long pause in GWIA load time is an indication that the GWIA has not succeeded yet to resolve the novell.com DNS query. In most cases after a while this screen will disappear and the normal GWIA console screen will appear, but this is a definite indication of a problematic or slow relationship between your GWIA and the DNS it's trying to access.
A fast and stable DNS service is important, because the GWIA will have to do one or more DNS queries for every email that will be sent. And in some cases the GWIA will even have to do DNS queries when receiving email, for example, when using the option Reject Mail If Sender's Identity Cannot Be Verified, as explained in Chapter 10 and shown in Figure 32.1. Figure 32.1. The GroupWise Internet Agent configuration Security Settings page showing the option Reject Mail If Sender's Identity Cannot Be Verified
Let's take a look at this subject in more detail. On a high level, when an email is being sent, the conversation goes like this:
Note It's essential that you understand the significance of step 6. Your GWIA will be able to communicate with all other SMTP servers only if your A records, MX records, and PTR records are configured properly. In real life we quite often see that the A and MX records are configured properly (otherwise nothing would work), but in too many cases the PTR records are not configured properly. This will be a problem only when sending mail to some Internet domains that are using an option like Reject Mail If Sender's Identity Cannot Be Verified, but of course for this high-availability solution we want this to be configured properly. This situation is of course a bit more complicated when you have more than one GWIA for your GroupWise system, as is discussed later in this chapter. Make sure that your hostname as shown to the outside world matches the DNS; for example, if on NetWare your HOSTNAME file in the SYS:\ETC directory contains an internal name like NW-FS01.clarify.nl, you might need to change the hostname. You will have to edit both the HOSTNAME file and the HOSTS file in the SYS:ETC directory to reflect the external name mail.clarify.nl. When changing this, make sure that certificate files used by this server also contain the same hostname.
Because you cannot configure your GWIA to use its own DNS servers, your GWIA relies on the proper configuration of the DNS services of the underlying operating system. You might want to check out the speed of several DNS servers; it might be surprising to know that in some situations the DNS service of your own provider is not the best (fastest) solution. If that's the case, you should consider configuring the DNS to go to a faster third-party DNS server. On NetWare you can do this in Inetcfg, Protocols, TCP/IP, DNS Resolver Configuration. In Windows and Linux there are similar tools. Note There is nothing wrong with having your GWIA point to an internal DNS server, which will actually try to offer answers from its own internal cache and will forward all new requests to some outside DNS server. This can indeed be faster than having to consult an external DNS server for every SMTP session. However, there is one caveat: Your own DNS server might cache this data for quite some time, and this could mean your GWIA will use stale information much longer than when connected directly to the external source. The problem is that if somebody makes changes to their DNS records, it will already take some time before these changes are propagated through the Internet, and with your own DNS server you've just added some extra latency to this process. This section explained why you need to spend some time looking at the configuration of your DNS lookups on your GWIA servers, because this is essential for a highly available GWIA. How Multiple MX Records Could Help You Create a Highly Available SMTP Service
Now let's consider what happens when somebody on the outside wants to send you a message via SMTP. As mentioned in the preceding section, the other person's SMTP server will ask for your MX record with the lowest preference number and, based on that information, will try to set up an IP connection with your SMTP server. Alas, for whatever reason, your GWIA is not running. The sending SMTP server will detect this unavailability. Then the SMTP server will query the DNS again to see whether there are any other MX record entries with the next higher preference number. If so, this server will try to set up a connection to this second SMTP server as well. If this also fails, most SMTP servers will query for the next MX record until it can set up an SMTP connection. So this mechanism gives you a lot of flexibility to set up your own incoming SMTP redundancy, especially if you combine this with a service that most ISP (Internet service providers) can offer, often called batch-SMTP or queued-SMTP. The idea behind batch-SMTP is that if your own SMTP servers are not available, your ISP will act as a fallback SMTP server for your domain. The SMTP server of the ISP will then accept all SMTP sessions for your domain and will queue all messages for you. Note There is one important aspect you need to understand: Your ISP's SMTP server has no clue what email addresses or message sizes are acceptable and therefore will have to accept all messages for you, even if it's spam that would normally be rejected by your own system. In the good old days of dial-up, batch-SMTP was quite common and even necessary, but nowadays this could lead to a rather large queue at the ISP. Therefore, certain ISPs are not so fond of this option anymore and don't offer this type of service unless you ask for it.
As soon as your own SMTP servers are back online, your ISP will detect their presence. The ISP will forward all the messages in the batch-queue to be handled by your own SMTP servers and will flush the queue. A More Detailed View of the DNS Records You Need for a Highly Available SMTP Service
So let's take a look at what do you need to do to enable multiple incoming GWIAs and batch-SMTP. Let's start with batch-SMTP first. You will need to talk to your ISP and ask them to set up this additional service for you. Make sure you understand how they're going to create this setup. It's especially important that you understand how they will detect whether your SMTP servers are back online again: Will they test that every few minutes? Will they ping the IP address of your SMTP server or the DNS name? Or are they trying to set up an SMTP session with your servers to detect your presence? After you've agreed on those details, your DNS will need to be reconfigured for the three record types, each of which are discussed in the sections that follow. MX Records
You will need an MX record for every server that will accept email for your system, for example as shown in Table 32.1.
The order of the MX records is important. In this case the first server that will be contacted for an SMTP session with clarify.nl is mail.clarify.nl, because it has the lowest preference number or preference value, 100. In this example you see that the second SMTP server to be contacted is mail2.clarify.nl with preference 105, and if both SMTP servers are unavailable the SMTP server mx.wirehub.net from the ISP will be used with preference 120. Tip There are several good tools that allow you to do DNS queries, but one of our favorites is online at www.dnsstuff.com. The tools of this site are available with a simple browser from almost anywhere. At the upper-right corner of this web page, you can go to the section DNS Lookup, select MX from the pull-down menu, and type in the domain name, and voilà!, there are the results as presented in these examples.
A more typical example of the usage of MX records comes from how Novell has its MX records defined. At Novell all three SMTP servers have the same preference value of 5, as shown in Table 32.2. This means that if any SMTP server tries to set up a connection to novell.com, any one of these three servers will be used at random.
A Records
Now that you have taken a look at the MX records, we need to define the proper A record as the hostname for every server that will accept email for your system, for example as shown in Table 32.3. What's a little surprising but not unusual is that the ISP has more than one IP address connected to the same hostname mx.wirehub.net.
The A records from Novell show a more typical example, without batch-SMTP; all three SMTP servers are internal servers, as shown in Table 32.4.
PTR Records
In most cases sending and receiving email will work with just a few MX records and A records, but as explained before you definitely need to look at your reverse address lookup or PTR records as well, as shown in Table 32.5. This table shows the result data for the lookup for mail.clarify.nl from www.dnsstuff.com, including the details to explain how the result came to be.
Now let's assume that something is wrong with one of the PTR records for Novell. If you look at the data given earlier in Table 32.2, the three servers that are accepting mail for novell.com all have the same preference. If an external SMTP server tries to connect with novell.com, the server will be assigned at random. Now take a look at the SMTP configuration in Table 32.6 and compare this to Table 32.2 and Table 32.4. There is a problem in this configurationcan you identify it?
Note For readability, the first few lines about "Preparation" and "How am I searching" are not repeated; the "Answer" section contains the relevant data.
The problem is of course the IP number 130.57.21.1 pointing back to IST_21_1.sjf.Novell.Com instead of pointing back to minotaur.novell.com. As you can suspect from the name IST_21_1.sjf, this is an internal server name that should not be used on the outside. And the problem is this: If the SMTP server that receives mail from novell.com has enabled the Reject Mail If Sender's Identity Cannot Be Verified option of the GWIA, not every session from novell.com would be accepted. Depending on the configuration, on average every one out of three sessions could be problematic. Of course, this example is not real; it is just a simulation of what could go wrong. Warning Always make sure that all your MX records have properly configured PTR records. If not, some external SMTP environments might not be able to process your mail properly. And although we like to advise you to enable the option Reject Mail If Sender's Identity Cannot Be Verified on the GWIA, the sad reality is that so many external SMTP servers are not configured properly that you might miss too many emails and your users would start complaining. They will mention that the other side has called them and that for whatever reasons your mail environment did not accept their "valid" mail. Even if you argue that this happens because of a misconfiguration at the other side, you will probably not win this battle. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||