Mailing List Message #9462
From: R. Scott Perry <>
Subject: Re:
Date: Tue, 06 Nov 2001 13:06:49 -0500
To: SIMS Discussions <>
X-Mailer: QUALCOMM Windows Eudora Version 5.1

First, the "nodata" response type is *not* defined by RFC2308.  It is
defined by RFC1034/1035, from eons ago.  RFC2308 just mentions what
implementations are out there.

While the "NODATA" response _is_ defined by RFC1034, the three different
types are clarified by RFC2308.

Correct.  So this type of response originated about 14 years ago, and isn't anything new.

As noted previously, these responses are for the purpose of OPTIONAL negative caching.

No.  The purpose of those responses is to report that the domain does not exist.  They do also contain negative caching information, that was updated in RFC2308.

RFC2308 attempts to now define negative caching as required, but from my experience negative
caching only ensures that something will continue NOT to work for an
even longer period of time than it would if negative caching were not used.

Yes, it does have that effect.  That's the drawback of caching, in the same way that if I have a TTL of a week for my MX records, and I have an IP as the MX record (big mistake!), that mistake will be cached for up to a week after I fix it.

I think the main reason for negative caching is for things like "yahoo.cmo" and "gotcha@spammers.must.die" or even "".

The drawbacks may outweigh the benefits, but that's something I don't care to get into (I don't have a strong opinion one way or the other).

It should also be noted, for the purposes of negative caching, that
Name Error responses (NXDOMAIN) can be cached as well, and (for this
particular example) would eliminate the problem that the "NODATA" response

True, but then you can't get across the fact that is a completely valid domain, although there are no MX/A records for it.  That's the point of the "nodata" response versus the "nxdomain" response.

RFC1035 specifically says the the NXDOMAIN response indicates that "the domain name referenced in the query does not exist", which isn't the correct case for (since the domain does exist).

I think we've determined that it is OpenTransport's resolver function that
does not correctly handle the "NODATA (Type 2)" response.

Yes, it appears that way.

 I'm sticking with my original stance that delays induced by sending a piece of mail with a
bogus return address (i.e., one for which there is no Mail Exchanger) are
the problem of the _sender_, not the recipient -- ditto if the "HELO" contains
a FQDN (Fully-Qualified Domain Name) that cannot be resolved.

Yes.  The sender should not normally be sending that invalid data.  Of course, if the situation is not handled properly, automated testers may not work properly, which seems to be the only drawback here.

IANA is the official group that keeps track of extensions to lots of Internet >protocols; they are pretty much a DNS authority.  If they do it, you can be >pretty sure it's correct and a standard.

It may be correct, but it is not (yet, anyway) a "standard" (STD).

It's definitely a standard; I can't say whether or not there is an RFC that references it that qualifies as STD in RFC terms.  But whether or not it is labelled as a standard, it should be handled properly.  For example, there's no RFC that says that Microsoft can't have security flaws in IIS, but that doesn't mean that it is OK.

This issue is that SIMS has an infinite loop, and causes potentially unlimited >network traffic.  That's bad, RFC or no RFC, standard or no standard.

Ah, but it has been noted that it _does_ time out.

Yes, but how much traffic can be sent during that time given fast network connections?

And I'm still sticking with my contention that it is the SENDER that is is causing these "bad"
things to happen, not the recipient.

I agree here, too -- but, the sender can't know that the bad things are going to happen, and the bad things are the result of a flaw in a DNS resolver.

Also note that I'm not letting OT off the hook for its loop, but I'd try to
get the sender to correct their system before I tried to get Apple to update
the OT stack (mostly because I'd likely have better luck with the former).

Good point.  In almost all cases, the sender should correct their system.  Given that little damage is done because of this, there doesn't seem to be a pressing need to fix OT.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster