Aaron Dewell wrote:
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.
One additional query is the problem. For example, a mail server running sendmail with a bind recursor. If sendmail has to check for the wildcard, it will have to check for *.com as well as example.com and do a set comparison to see if example.com is a wildcard. For every new process, this has to be repeated, doubling the number of queries on the recusor. If, however, the recursor performed the processes, caching *.com for the TTL and recognizing that all domains resolving to its set is also a wildcard, and caching/marking them as such, then the resolver can request the record, without wildcards, on behalf of sendmail. This means one query to the recursor who has properly cached 1) the domain record, 2) if the domain record is a wildcard, and 3) the wildcard set. This is about the minimal number of queries that can be performed across the board. Applications that want to accept the wildcard would ask the record normally (accepting wildcard). -Jack