Subject: 1024 clarification regarding wildcard records

From: Jeff Schreiber <[email-masked]>
Date: Wed, 20 Jan 1999 13:34:48 -0400

I'm looking for a little clarification of the wildcard section (4.3.3) of 
    RFC 1024. 
-------------
[...]
This facility is most often used to create a zone which will be used to
forward mail from the Internet to some other mail system.  The general
idea is that any name in that zone which is presented to server in a
query will be assumed to exist, with certain properties, unless explicit
evidence exists to the contrary.  Note that the use of the term zone
here, instead of domain, is intentional; such defaults do not propagate
across zone boundaries, although a subzone may choose to achieve that
appearance by setting up similar defaults.
[...]
   - When the query name or a name between the wildcard domain and
     the query name is know to exist.  For example, if a wildcard
     RR has an owner name of "*.X", and the zone also contains RRs
     attached to B.X, the wildcards would apply to queries for name
     Z.X (presuming there is no explicit information for Z.X), but
     not to B.X, A.B.X, or X.
[...]
To illustrate the use of wildcard RRs, suppose a large company with a
large, non-IP/TCP, network wanted to create a mail gateway.  If the
company was called X.COM, and IP/TCP capable gateway machine was called
A.X.COM, the following RRs might be entered into the COM zone:

    X.COM           MX      10      A.X.COM

    *.X.COM         MX      10      A.X.COM

    A.X.COM         A       1.2.3.4
    A.X.COM         MX      10      A.X.COM

    *.A.X.COM       MX      10      A.X.COM
[...]
-----------------------

    The part I'm unclear about is in the second quoted section.  Is the
    text "and the zone also contains RRs attached to B.X" intended to
    imply "contains any RRs, regardless of type", or "contains any RRs
    of the same type".  

    The first quoted section mentions "unless explicit evidence exists to
    the contrary".  Now I would take explicit evidence to be the existance
    of an MX RR for the specific name.  But I would take the existance of
    an A RR for the specific name to not be explicit evidence to not reply
    with the wildcard MX record.

    To explain the situation I'm discussing:

    X.COM           MX      10      Z.X.COM

    A.X.COM         A       1.2.3.4
    A.X.COM         MX      10      A.X.COM
    B.X.COM         A       1.2.3.5

    *.X.COM         MX      10      Z.X.COM

    An MX lookup for XXX.X.COM will result in Z.X.COM.  An MX lookup for
    A.X.COM will result in A.X.COM.  What should an MX lookup for B.X.COM 
    result result in?  The wildcard Z.X.COM answer or NOERROR/noanswer?

    I would think it should return the wildcard MX [since there isn't any MX 
    for B.X.COM to suggest otherwise], otherwise the use of wildcard MX records
    seems fairly useless, since it will only match lookups for names that
    don't exist at all, and you would have to duplicate the wildcard MX for
    all the names in your zone.  (and since I could care less if I route
    mail sent to [email-masked], it seems sort of foolish)

                                                -Jeff

--
Jeff Schreiber,            Process Software Corp.
[email-masked]   http://www.process.com
      TCPware & MultiNet: Stronger than Ever

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 21 Jan 1999 17:36:07 -0600

You mean 1034, not 1024, yes?

>     imply "contains any RRs, regardless of type", or "contains any RRs

Regardless of type.  If B.X has any type of RR, then a wildcard at
*.X does not apply to B.X or any subdomains of B.X.

>     I would think it should return the wildcard MX [since there
>     isn't any MX for B.X.COM to suggest otherwise], otherwise the
>     use of wildcard MX records seems fairly useless, since it will
>     only match lookups for names that don't exist at all, and you
>     would have to duplicate the wildcard MX for all the names in
>     your zone.

At one point in the dim past I thought it ought to be the way you
wish, although there was never any doubt in my mind that the spec
said it was the other way.  But now I agree that the way it's
designed is better.

Remember, you can wave a simple algorithm over your zone file before
you give it to your DNS server if you want certain records attached
to all names.  But if wildcards applied to all names, there would be
no way to undo them for certain names and have nothing in their
place.

---

From: Robert Elz <[email-masked]>
Date: Fri, 22 Jan 1999 13:15:55 +1100

Date:        Wed, 20 Jan 1999 13:34:48 -0400
    From:        Jeff Schreiber <[email-masked]>
    Message-ID:  <[email-masked]>

  |     An MX lookup for XXX.X.COM will result in Z.X.COM.  An MX lookup for
  |     A.X.COM will result in A.X.COM.  What should an MX lookup for B.X.COM 
  |     result result in?  The wildcard Z.X.COM answer or NOERROR/noanswer?

The latter, not the wildcard.   If that were not true there would be no
way to get the noanswer result (this name has no MX record).   To get the
Z.X.COM answer all that is needed is to add an explicit MX record to
B.X.COM.

  |     I would think it should return the wildcard MX [since there isn't
  |	any MX for B.X.COM to suggest otherwise], otherwise the use of
  |	wildcard MX records seems fairly useless,

No.

  |	since it will only match lookups for names that don't exist at all,

No, names that are not in the DNS at all.   The intent of wildcards
was for zones where the DNS has no real notion of what is in the namespace.
These days that is comparatively rare - back when 1034 (and 881) were
written it was very common for entire countries to be in the DNS as a
single wildcard (and the necessary stuff, SOA and NS to make the DNS work).
Even after that, before HTTP became almost anyone cared about, when e-mail
was the major reason for being on the internet, large numbers of domains
were implemented largely with a wildcard MX record.

  |	and you would have to duplicate the wildcard MX for
  |     all the names in your zone.

If they're all intended to have the same MX value, then yes.   (Of
course, a server could have some way to automate that if desired).

  |	(and since I could care less if I route
  |     mail sent to [email-masked], it seems sort of foolish)

That's true, which is why for many people wildcards are useless, and
should generally not be used.

But I can assure you that mail to Australia (and may other places) would
never have arrived anywhere had we had to attempt to list every valid
name in the DNS, a wildcard *.oz.au directing mail to our gateway (up
to just about 10 years ago) really was a useful thing to have.

The distinction is whether the maintainer of the DNS wants to also maintain
the valid sub-domain list, or if they want to defer that to some other
entity, with traffic to it being over some non internet protocols.

kre