Mailing List Message #9400
From: Michael A. Pasek <>
Subject: Re: Fwd: Resolving the HELO Argument
Date: Sat, 3 Nov 2001 11:54:42 -0600
To: <>
On 11/02, Warren Michelsen <> wrote:
Excerpts from my correspondence with the guy at All the text is from him; I've edited out my part.


Interspersed below...

When our DNS servers receive a request for the A record of, they
will immediately reply with a "nodata" response.  ...

Is that a TYPE 1 or a TYPE 2 "NODATA" response ?  RFC2308 specifically notes
that "There are a large number of resolvers currently in existence that fail
to correctly detect and process all forms of NODATA response.  Some resolvers treat a TYPE 1 NODATA response as a referral."

The problem seems to be that SIMS chokes when it gets the "nodata" response
(which indicates that the host name *is* valid, but there is no A record for
it), as opposed to a "nxdomain" response (which indicates that the host name is >not valid, and there is no A record for it). "" will return the
"nodata" response, whereas "" would return a
"nxdomain" response (and SIMS won't choke on that).

I'm guessing that the DNS engine that SIMS uses doesn't process the "nodata"
response correctly, gets stuck in an infinite loop, and times out after 45

Apparently what this guy is saying is that the OpenTransport resolver is
acting precisely like the RFC warns that it might ?  The "infinite loop",
I assume, would be querying ALL listed nameservers to see if one of the
_other_ nameservers might know something different....

Also, I haven't read the RFC closely, but how would a secondary server respond
  a) the TTL for an A record had expired, but the zone itself is still valid;
  b) it has not been able to contact the primary to refresh the zone.
Should this result in a "NODATA" response, and should it be TYPE 1 or TYPE 2 ?
What the OT resolver does in this case (i.e., query the other nameservers)
would be the desirable action, since it will result in the correct answer once
the primary (or a secondary with an unexpired "A" record) is queried.  This
also points out one of the flaws of the noted RFC, and one of the main reasons
why Negative Caching was considered to be a BAD_THING:  There are times when
negative anwers will occur (ever have a typo in a zone file ?), and you
DON'T want those answers cached (and propogated), particularly if you've
got the "TTL for negative responses" on the SOA record set to something like
a month.  Some would argue that you could elimiate this problem by having
a small TTL here, but then that defeats the whole point of negative caching,
doesn't it ?  Even 1 day (see next quoted paragraph) of "NODATA" responses,
when those occur because of that typo in your zone file (which you
corrected 5 minutes later), would seem to be a _very_ undesirable result.

<sigh>  We've been over this -- if you are right, it should take the same
amount of time on average to resolve "" and ""
(unless the lookup is not following the RFCs).  And, the response the second
time should be immediate, as the results should be cached.  The RFCs (RFC2308)
require the DNS server that SIMS uses to cache the negative response for for 24 hours.

Again, the OT resolver is probably NOT following this specific RFC (2308),
as it is, as the name implies, a "Request for Comments", _not_ an STD,
or Internet STANDARD.  Therefore, while it may be on the "Standards Track",
it is NOT YET a standard, and as such its implementation is optional.  Also,
as noted above (from the RFC), "There are a large number of resolvers
currently in existence that fail to correctly detect and process all forms
of NODATA response."  So, what the DNSReport people are saying is that they've
implemented their DNS such that "a large number of resolvers" will fail to
work properly with their DNS ?

[time comparison between "NXDOMAIN" and "NODATA" responses deleted]
...  you'll need a mail server that caches the DNS entries, and handles the
"nodata" response according to the RFCs.  :)

Actually, it is NOT SIMS's responsibility to do this, but the resolver (or
an upstream nameserver).  Since the benefits (to the end user) of negative
caching are minimal (at best) and many resolvers and name servers do NOT
do negative caching, then until RFC2308 becomes a standard (and I doubt
that it will), I'd say the OT resolver is behaving properly by not
implementing the "optional" negative caching (as specified in the STD), and
that DNSReport is out there on the "bleeding edge" (and suffering for it).

I think at this point the only issues are that SIMS isn't caching DNS entries,
and is choking on the "nodata" response; and that the DNS report isn't
following RFCs completely (although I think the only issue now is the "RCPT
TO:" that uses, which causes a delay -- probably because of the
"nodata" response for

It's not SIMS's responsibility to cache DNS entries, and we still don't
know if that's a TYPE 1 or TYPE 2 "NODATA" response.  And he finally admits
that "DNS report" is not following their touted RFCs!

[remainder deleted]

My $.02:  The RFC in question makes _way_ too many changes to existing DNS
architecture without ensuring backward compatibility.  I'd say that you
should tell DNS Report to implement their systems using Internet STANDARDS,
not experimental concepts.....

Michael A. Pasek
Pasek Consulting, Inc.
9741 Foley Boulevard NW
Coon Rapids, MN  55433-5616
(612) 597-5977
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster