Re: Root Server Operators (Re: What *are* they smoking?)

[Aaron Dewell <acd () woods net>]

On Wed, 17 Sep 2003, Jack Bates wrote:
> One method that might be considered for recursive servers as well as
> resolvers, is the ability to specify if a wildcard entry will be
> accepted or not, perhaps at any level or just at the 2nd level. Cached
> records which are wildcards could be marked as such so that subsequent
> queries could specify desire of accepting or not accepting the wildcard
> entry. A web browser, for example, which supports its own redirections
> for NXDOMAIN, might wish to ignore the wildcard records, as would smtp
> servers.

Verisign is at least using 15 minute ttls on the wildcards.  Not that
I think a wildcard in .com/.net is a great idea, but with the low ttls,
it won't cache that long.

> While I believe that net and com should never have wildcards, the
> ability to detect, cache, and override wildcards for tld's such as
> .museum when the application requires it is paramount. I realize that
> the client software can perform the queries and detection itself, but in
> many cases, there wouldn't be an effecient way to cache the information
> without the resolver and recursive cache being aware of the process and
> performing such detection would require two queries versus one.

What if there was a requirement to add something that would work as a
wildcard, but also be easily detected as a wildcard with one additional
query?  thisisawildcard.*.com IN A 127.0.0.1 or something.  One additional
query, and applications can decide whether they want a wildcard result or
not.  That could be added to spam filters to make them work again.

I'm not sure if one can use wildcards in that way, but that would solve
the problem and let them keep their wildcards, and put the ball into
the court of the application developers.

Aaron