wildcard and subdomain wildcard leaves a gap

[Phil Howard]

On Wed, Jan 28, 2004 at 09:28:14AM +0100, Erik Rozendaal wrote:

| Phil Howard wrote:
| >However, when I query just foo.ham.org I get nothing.  The *.foo stuff
| >does not match (I didn't expect it to), but the * stuff does not match,
| >either (I expected that if it would not match *.foo it would at least
| >fall back to match *).
| 
| This is expected behavior.  When you define *.foo you also implicitly 
| define foo (as an empty non-terminal).  This will match a query to 
| foo.ham.org but will not have any data to match with so you get an empty 
| answer.
| 
| The same kind of stuff happens when you define:
| 
| *   IN TXT "wildcard text"
| foo IN A   127.0.0.1
| 
| A query for <foo, IN, TXT> will _not_ match the wildcard text record. 
| You'll get a "no TXT record at foo" error instead.

This I expect to happen.

FYI, I am working on building my own name server for a different purpose
than NSD.  It will have a number of complex methods for synthesizing RRs
as queried.  Regular expressions might be used, for example.  Also, aspect
overlays will be a feature that would allow the TXT to be provided for
"foo" in the above example.  But that's not wildcard in the same sense.

So why is an RFC even defining the method of synthesis?  I suspect it is
because there needed to be a standard so that zone transfers could be done
in a meaningful way.  RFC defined zone files have no way to do anything
more complex than a "*", and likely never will.  So all the stuff I would
be doing to synthesize records differently would be out of scope for a
zone file, and in fact can't use RFC zone files to work, anyway.

Unlike the simplicity of NSD, my name server will have a configuration file
that could get complex.  It will function more like a policy description
and allow decisions to be made based on various pieces of information in
the query and in the data.  Perhaps the first use I will make of it is to
handle SPF "exists:" queries being sent back that include client IP and
sender email address, and perform the "designated sender" tests based on
whether the client IP is one in which that sender username has logged in
on POP/IMAP in the past hour.  That would allow my users (almost all of
which don't use my IP address space), to send email directly from their
IP (or via their ISP mail server with a more complex test), with SPF being
fully active to reject spammer forgery attempts from elsewhere (where the
MX host is testing SPF).


| This all explained pretty well in the wildcard clarify draft document, 
| which the NSD algorithm is based on.  You can find the document at 
| <URL:http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-02.txt>

Thanks.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------