levitz@theta.cs.fsu.edu (Hilbert Levitz) (06/27/91)
We have evidence that our 5.65 mailers do not use the name server
cache, but instead go to an authoritative server for each query.
Can anyone tell me wheter this is normal or wheter this might
be an error of installation or configuration?
Also, if it's normal, is it really legal to be set up this way.
I'm under the impression that the use of a cache is required by
the Internet.
Please respond directly to me.
Hilbert Levitz
levitz@cs.fsu.edu
--rickert@mp.cs.niu.edu (Neil Rickert) (06/27/91)
In article <1991Jun26.194529.24019@mailer.cc.fsu.edu> levitz@theta.cs.fsu.edu writes: >We have evidence that our 5.65 mailers do not use the name server >cache, but instead go to an authoritative server for each query. > >Can anyone tell me wheter this is normal or wheter this might >be an error of installation or configuration? Neither. It is an error of confusion (yours). >Also, if it's normal, is it really legal to be set up this way. >I'm under the impression that the use of a cache is required by >the Internet. Sendmail is just using the standard resolver library. It consults the local nameserver (or which ever server is listed in /etc/resolv.conf). Thus if the record is in the local nameserver's cache it is used. If not, the local nameserver will attempt to find the record. Sendmail will not accept a non-authorative negative answer, since that might result in incorrectly bouncing mail. Whereas 'telnet' might say "host not found" if the nameserver data cannot be found within a short period, sendmail will try for a longer period of time, and if an answer cannot be found, will queue the message for later attempts. But note that NXDOMAIN is a response, and this will cause the mail to bounce with "Unknown host - authoratative answer from name server". Most likely what you are seeing is long delays finding records, and you are misinterpreting this. Consider the following scenario. You send two messages to u@f.q.d.n The first message takes a long time, which you interpret as a delay looking up DNS records. But the second message takes just as long, which you are misinterpreting as failure to use data from the cache. Here are a couple of causes for the long delay. (a) The DNS record has a very short TTL, and has timed out before the second lookup. At times secondary nameservers emit records with a TTL of 120 seconds, which can cause this problem. This is fixed in 4.8.3. (The nameserver with SunOS 4.1 has this problem - if you have such a system and are a secondary nameserver, install bind 4.8.3). (b) The host f.q.d.n has an A record but no MX record. For the first message, the A and MX records are looked up. The A record is copied into the local cache. The MX record doesn't exist, so there is nothing to cache. For the second message, since proper processing of mail requires an MX record lookup, sendmail must again request the MX record. Since it is not in the cache, the full lookup must proceed again. It is a good idea to always have an MX record, even if it only points to the same host name, just to be sure there is something to cache. Another option is some sort of negative caching. But to do this properly will require some design changes. The NXDOMAIN or NODATA response would have to have a TTL, and the nameserver would have to construct the requested MX (or other) record, assign it this TTL, and flag it as NXDOMAIN or as NODATA. Getting everybody to use MX records for all valid addresses is the easier solution, since the main losers are on the host which fails to have an MX, and thus is more likely to have mail for it queued and delayed. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
woods@ncar.ucar.edu (Greg Woods) (06/27/91)
There is a possible reason for thinking that sendmail isn't using the DNS cache, and that is sendmail's insistence on checking MX records. If there is an A record in the local name server's cache, but no MX, sendmail will insist on querying the authoritative server to get an MX record (or an authoritative response indicating that there is no MX), thus appearing to "ignore" the locally-cached data. In this case however, sendmail's behavior is correct, for the presence of an A record does not guarantee that the proper thing to do is send the mail direct. Lots of hosts (including all of our diskless workstations) have valid A records but CANNOT receive their own mail, they are all MX'ed to the appropriate server host. --Greg