On Wed, 17 Sep 2003, Jack Bates wrote:
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.
The comparison could be eliminated with the thisisawildcard flag or similar, but either way, yes, it doubles the number of lookups. Not ideal, but it works, and given that Verisign is going to continue to do what they are doing unless DoC or ICANN tells them not to (may or may not happen), this makes a reasonable backup plan. If DoC and ICANN won't tell them to knock it off, they might tell them to make it more obvious in this way. Yes, it's more overhead for everyone else to make up for their brilliant marketing idea, but it would work. What other plan does everyone have if ICANN says "Oh, it's ok, we don't mind, whatever they want to do is fine"? How many people (realistically) are going to deploy the ISC patch? When Paul Vixie says he doesn't really like it? And it's only available for BIND 9? As someone else pointed out, this battle is in a completely different arena. MSN and AOL aren't going to implement the patch, guarenteed. They _might_ redirect traffic to that IP to their own site. And only that until a lawsuit gets filed. The point is, this makes a reasonable backup plan. Far from ideal, but we're dealing with a state-supported monopoly who can do whatever they want. Get this in place, then think about how to throw the monopolies out. This works in the meantime. They will likely compromise this far, even if they won't back down. If the IPv6 specs were modified somewhat, one could assign a prefix to everyone and every organization, and use a registry to map them, like the ID system that someone else mentioned (sorry, I don't have the email in front of me). Those projects could be combined to solve the problem for all time. That's a separate issue that needs more research.
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).
The TTL is 15 minutes, so your hypothetical server would be throwing away it's cache every 15 minutes. Then re-querying everything. You'd have to have a _lot_ of outgoing email to justify that. This solution still requires increased overhead, and more modifications to BIND. Which has more impact on your server, this BIND overhead, or one additional query from your MTA? My guess is the query is cheaper overall. And you have to convince ISC to implement these changes, or write them yourself, then you have the potential cost of an unstable nameserver. Overall, I'd take the one addition query based on the compromise solution. Aaron