Implementing wildcards

To implement a "wildcard" (e.g. DNS wildcard, DMARC wildcard, or /64 wildcard, you basically "reduce" a lookup to a point where that lookup is the same for all keys shared by that wildcard.

For example: DMARC

Let's say that we need to look up the DMARC record for one.two.test.example, but only has an DMARC record.

According to the standard, the following lookups are performed:

  • dig -t TXT
  • dig -t TXT _dmarc.two.test.example
  • dig -t TXT _dmarc.test.example
  • dig -t TXT _dmarc.example

Here, there is no DMARC record for one.two.test.example, so the policy prevails.

Similarly, for three.four.test.example:

  • dig -t TXT _dmarc.three.four.test.example
  • dig -t TXT _dmarc.four.test.example
  • dig -t TXT _dmarc.test.example
  • dig -t TXT _dmarc.example

In both cases, the DMARC policy for test.example is checked, even though they are originally on different subdomains. This procedure of checking less specific domains means that even if a wildcard match cannot be done (e.g. when the lookup is done by binary search), checking less specific domains allows the lookup of the less specific domain to also apply to all of its subdomains.

Another example: SSL

Let's say that we want to verify the SSL certificate for As I understand it, the subject alternative name portion would need to have one of two exact strings:

  • * (i.e. leftmost label replaced with a star)

If either of those exact strings are present in the SANs, then the certificate passes the hostname check.

Similarly, would require one of these SANs:

  • *

Because both of these examples include '*', a wildcard SSL certificate for '*' would cover any subdomain directly under

Essentially, we have "reduced" the specific leftmost label by replacing it with a star. In general, by mapping a larger set to a smaller set, we have basically allowed the smaller set to represent multiple elements from the larger set.