Dear tbach-ga,
While I'd really need to see the zone file in question to diagnose
your problem with certainty, I strongly suspect that this particular
counter-intuitive behaviour is to blame:
What are the limitations of wildcards? Wildcards do not match names
for which there is already data. Suppose you did use wildcards within
your zone data, as in these partial contents of db.movie:
* IN MX 10 mail-hub.movie.edu.
et IN MX 10 et.movie.edu.
jaws IN A 192.253.253.113
fx IN NS bladerunner.fx.movie.edu.
fx IN NS outland.fx.movie.edu.
Mail to terminator.movie.edu will be sent to mail-hub, but mail to
et.movie.edu will be sent directly to et. An MX lookup of
jaws.movie.edu would result in a response that said there was no MX
data for that name. The wildcard doesn't apply because an A record
exists. The wildcard also doesn't apply to domain names in
fx.movie.edu, because they don't apply across delegation."
- "DNS & BIND", Third Edition, Cricket Liu & Paul Albitz,
O'Reilly & Associates, 1998
http://www.defcon1.org/e-books/ch15_02.htm
"Does BIND not understand wildcard MX records such as the following?
*.foo.com MX 0 mail.foo.com.
No. It just doesn't work.
Explicit RR's at one level of specificity will, by design, "block" a
wildcard at a lesser level of specificity. I suspect that you have an
RR (an A RR, perhaps?) for "bar.foo.com" which is blocking the
application of your "*.foo.com" wildcard. The initial MX query is thus
failing (NOERROR but an answer count of 0), and the backup query finds
the A RR for "bar.foo.com" and uses it to deliver the mail directly
(which is what you DIDN'T want it to do). Adding an explicit MX RR for
the host is therefore the right way to handle this situation.
See RFC 1034, Section 4.3.3 ("Wildcards") for more information on this
"blocking" behavior, along with an illustrative example. See also RFC
974 for an explanation of standard mailer behavior in the face of an
"empty" response to one's MX query.
Basically, what it boils down to is, there is no point in trying to
use a wildcard MX for a host which is otherwise listed in the DNS.
It just doesn't work."
- Question 5.9: wildcard MX records, comp.protocols.tcp-ip.domains
FAQ
http://www.intac.com/~cdp/cptd-faq/section5.html#mx
If you have any other records for the domains you're trying to match,
in other words, your wildcard MX record won't match them. You'll need
explicit MX records for them.
If this answer isn't quite what you're looking for, please feel free
to request a clarification.
cerebrate-ga
Search strategy:
Personal knowledge as hostmaster
Google search, "wildcard MX records" -
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=wildcard+MX+records |
