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