Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"TLAM%HKUCC.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 27 Sep 92 00:11:54 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Illegal host/domain and MX
Newsgroups: bit.listserv.pmdf-l

> When sending to an MX'ed site, for instance thp.uni-koeln.de, PMDF bounces
> with an "illegal host/domain".  If I send it again, it goes through OK.
> NSLOOKUP shows the site is MX'ed.  Could there be a timeout with the MX
> lookup?  Any suggestion to fix the problem is much appreciated.

First of all, you mention the possibility of a timeout being a source of
trouble. This isn't possible. It certainly is possible for a DNS query to time
out -- they do it all the time. But when this happens PMDF doesn't get any
information about the validity of the domain and therefore it takes no action.

The only time PMDF ever bounces a message because of a bogus domain is when the
DNS explicitly says "I have never heard of that domain". In other words, any
kind of DNS failure, be it timeouts, bogus responses, or whatever, are handled
as temporary failures and PMDF tries again later. PMDF only bounces messages
when the DNS has assured PMDF that the domain is in fact illegal. A definitive
answer is always required for PMDF to take definitive action.

But this still means that messages are improperly bounced because the DNS can
be incorrect. Problems of this sort (it doesn't work and then it does) are
commonplace with the DNS in general and MX records in particular.

The DNS is an unsynchronized distributed database. It uses a huge amount of
caching to boost performance to acceptable levels. The closest thing the DNS
has to a synchronization mechanism is expiration times for each chunk of data,
and these times are often set far too large.

The DNS is supposed to always be sliding down an asymptotic slope towards total
correctness. The problem is that the meaning of "totally correct" changes from
one second to the next and so the DNS is always playing a catch-up game trying
to get sychronized. It never makes it, of course -- the goal is totally
elusive.

This is far from a design problem in the DNS. It is in fact a major design
goal, and it is the only way that's known for implementing a extremely
large-scale fully distributed database.

All this means is that once bogus information is spread (and missing
information about something often counts as bogus information) it can take time
for it to go away (sometimes seconds, sometimes hours, and sometimes weeks).
And this in turn means that it is very very common to see results where
something doesn't work and then it does. Situations where something works
and then it doesn't also occur (this happens when conflicting sources of
cached information are used; some correct and some not).

In any case, PMDF has nothing to do with any of this. PMDF simply constructs
queries and sends them to the DNS resolver on your system. (This is almost
always part of the TCP/IP package you're using.) The resolver either pulls the
information out of its local cache or contacts other DNS resolvers to answer
the query. Once the query has been resolved the result is returned to PMDF, and
PMDF then acts on the information it receives.

There are no knobs to turn on PMDF to change any of this. Any knobs that exist
are part of the resolver you are using. And most resolvers only have a few very
gross adjustments (things like whether to be a slave or caching server or
whatever). There really aren't many more tunable things in a modern DNS
resolver.

If this is a situation where you got a couple of bounced messages and now
things are working my advice it to grin and bear it because it is simply the
way the network operates. If you're seeing some sort of pathological behavior
where all queries first fail and then work I would recommend evaluating the way
you have DNS things set up at your site. There are various ways to do it and
you may well have chosen a bad one that's causing trouble.

                                Ned

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU