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