I've been using wildcards in one of my domains for a while, and recently
even added a TXT record for SPF as a wildcard:
For ham.org:
* 12h IN A 209.102.192.73
* 12h IN AAAA ::FFFF:209.102.192.73
* 12h IN TXT "v=spf1 a mx ip4:209.102.192.64/27 ip4:209.102.208.16/28 ptr:ham.org -all"
This works just fine. Today I tried something different to see how it would
behave. The behaviour I saw was not quite what I expected and seems a little
inconsistent. I added the following records:
*.foo 2h IN A 209.102.192.64
*.foo 2h IN AAAA ::FFFF:209.102.192.64
*.foo 2h IN MX 0 .
*.foo 2h IN TXT "v=spf1 -all"
*.spf 1h IN A 209.102.192.74
*.spf 1h IN AAAA ::FFFF:209.102.192.74
*.spf 1h IN MX 0 .
*.spf 1h IN TXT "v=spf1 -all"
When I query xyzzy.foo.ham.org I get the A and AAAA records just fine as
expected:
;; ANSWER SECTION:
xyzzy.foo.ham.org. 7200 IN A 209.102.192.64
xyzzy.foo.ham.org. 7200 IN TXT "v=spf1 -all"
xyzzy.foo.ham.org. 7200 IN MX 0 .
xyzzy.foo.ham.org. 7200 IN AAAA ::ffff:209.102.192.64
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 *).
Can someone tell me if this is the RFC specified behaviour (it seems odd
that it would match neither) or if this is a bug in NSD? Why should the
existance of *.foo affect a lookup of foo without providing its data?
In case something else I put in the zone file is the culprit, here is a
URL to access the whole zone file as input to zonec:
http://ham.org/ham.org.zone.txt
Here are digs I did to check on this:
Phil Howard wrote:
I've been using wildcards in one of my domains for a while, and recently
even added a TXT record for SPF as a wildcard:
For ham.org:
* 12h IN A 209.102.192.73
* 12h IN AAAA ::FFFF:209.102.192.73
* 12h IN TXT "v=spf1 a mx ip4:209.102.192.64/27 ip4:209.102.208.16/28 ptr:ham.org -all"
> [...cut...]
*.foo 2h IN A 209.102.192.64
*.foo 2h IN AAAA ::FFFF:209.102.192.64
*.foo 2h IN MX 0 .
*.foo 2h IN TXT "v=spf1 -all"
*.spf 1h IN A 209.102.192.74
*.spf 1h IN AAAA ::FFFF:209.102.192.74
*.spf 1h IN MX 0 .
*.spf 1h IN TXT "v=spf1 -all"
[...cut...]
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 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>
Erik
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.