any requests

[Vernon Schryver]

> From: Tony Finch <dot at dotat.at>

> > a few minutes playing around, you might come to my conclusion.  I think
> > they treat ANY as if it were psuedo-rdataset containing some of the
> > RRs for the domain with a TTL equal to the minimum of all of the TTLs
> > of the contained rdatasets.  (I thought I sometimes get only some of

> I thought Google Public DNS re-fetched RRsets as they were expiring in
> order to keep the cache populated, which would explain what you see, 

I don't understand how they could pre-fetch the gazillions of RRsets
that are rarely requested.  It certainly doesn't explain what I see
in DNS queries and responses and in my server logs with a test domain
with a dozen fat RRsets with TTLs ranging from 5 to 65 seconds.
(They started SERVFAILing when I added the last RRset; I don't know whether
they don't like bogus DNSKEYs, I tested too much, or I hit a size limit.)

I'd be happy to disclose my test domain name in private mail, but that
wouldn't get my server logs.  Only one of us could play with it at a
time.  You could add to a zone of your own and start testing faster
than I could answer private mail.


> It was a bad hack then and it has remained a bad hack :-)

I would not agree if you could rely on the open resolvers continuing
to do what they're doing, if you didn't care about parsing 3 or 4
KBytes of irrelevant bits to get the RRsets you want, and if you don't
care about spending 9 or 10 IP packets on a truncated UDP responce and
then a full TCP response instead of 6 on 3 separate queries.

With BIND as your DNS server, it could be a win for bursts of mail to
a single SMTP server if your SMTP client is too dumb to do the obvious,
safe caching.  At worst you would need to ask for ANY, MX, A, and AAAA,
but some of the time the ANY would have all of the RRsets.

However, in both cases, the proverb applies.
"If wishes were horses, beggars would ride"


Vernon Schryver    vjs at rhyolite.com