[62300] in North American Network Operators' Group
Re: Root Server Operators (Re: What *are* they smoking?)
daemon@ATHENA.MIT.EDU (Jack Bates)
Wed Sep 17 12:01:53 2003
Date: Wed, 17 Sep 2003 11:00:50 -0500
From: Jack Bates <jbates@brightok.net>
To: Aaron Dewell <acd@woods.net>
Cc: nanog@merit.edu
In-Reply-To: <Pine.LNX.4.44.0309170911350.25233-100000@dragon.woods.net>
Errors-To: owner-nanog-outgoing@merit.edu
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
