On 11/02, Warren Michelsen <[EMAIL PROTECTED]> wrote: >Excerpts from my correspondence with the guy at DNSReport.com. All >the text is from him; I've edited out my part. > >Commments?
Interspersed below... >When our DNS servers receive a request for the A record of dnsreport.com, 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). >"dnsreport.com" will return the >"nodata" response, whereas "madeuphostname.dnsreport.com" 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 >seconds. 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 if: 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 "dnsreport.com" and "www.dnsreport.com" >(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 >dnsreport.com 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 example.com, which causes a delay -- probably because of the >"nodata" response for example.com). 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 [EMAIL PROTECTED] ############################################################# This message is sent to you because you are subscribed to the mailing list <[EMAIL PROTECTED]>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
