Most often, you'd use wildcards to forward mail to non-Internet-connected networks. Suppose our site weren't connected to the Internet, but we had a host that relayed mail between the Internet and our network. We could add a wildcard MX record to the movie.edu zone for Internet consumption that points all our mail to the relay. Here is an example:
Since the wildcard matches one or more labels, this resource record would apply to names such as terminator.movie.edu, empire.fx.movie.edu, or casablanca.bogart.classics.movie.edu. The danger with wildcards is that they clash with search lists. This wildcard also matches cujo.movie.edu.movie.edu, making wildcards dangerous to use in our internal zone data. Remember that some versions of sendmail apply the search list when looking up MX records:*.movie.edu. IN MX 10 movie-relay.nea.gov.
What are the limitations of wildcards? Wildcards do not match domain names for which there is already data. Suppose we did use wildcards within our zone data, as in these partial contents of db.movie.edu:% nslookup Default Server: wormhole Address: 0.0.0.0 > set type=mx -- Look up MX records > cujo.movie.edu -- for cujo Server: wormhole Address: 0.0.0.0 cujo.movie.edu.movie.edu -- This isn't a real host's name! preference = 10, mail exchanger = movie-relay.nea.gov
Mail to terminator.movie.edu is sent to mail-hub.movie.edu, but mail to et.movie.edu is sent directly to et.movie.edu. An MX lookup of jaws.movie.eduwould result in a response saying there was no MX data for that domain 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 wildcards don't apply across delegation. Nor does the wildcard apply to the domain name movie.edu, because the wildcard amounts to zero or more labels followed by a dot, followed by movie.edu.* 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.