I did not find the DNS namedroppers discussion of wildcards to be
particularly helpful, it consisted mostly of statements of the form
'that cannot work, you must do everything our way' followed by an
admission that that approach suffers from the same problem.
It is empirically entirely possible to introduce wildcards of the form
_prefix.*.example.com into the DNS. If anyone would like a demonstration
take a look at several of the toplevel domains that have 'synthetic'
wildcards for www.*.tld
The real problem here is teminological. The DNS wildcard is defined in a
particular way, it matches a node if and only if the node does not
exist. That is not the behavior that is generally desired for policy
extensions. This means that *.example.com does not meet the required
functionality of 'everything in the zone that does not have an explicit
policy stated' either, even if a new RR is defined.
The wildcard does not need to be a part of the DNS protocol except in
respect of two features. The first of these is the DNS zone transfer
mechanism which is a not a part of core DNS functionality any longer -
try and do a zone transfer from the .com or .de zone. It is not a major
problem for management of DNS if you can only transfer your zone file to
DNS servers that meet a certain level The second area is DNSSEC and that
is still fixable.
So no, it is not at all correct to say that it is not possible to fix
the wildcard issue and anyone claiming that to do so would require major
upheavals in DNS is not correctly advised.
If you don't care about DNSSEC the problem can be fixed today through a
simple modification to the DNS server that publishes the records.
If you do care about DNSSEC and do not want to change it your options
are more limited but it is still not necessary to introduce new RRs for
each new security policy definition. Instead you can use the prefix
mechanism in combination with a macro processor to generate policy
records for nodes that are defined but do not have a specified policy.
This leaves you with the problem of how to deal with undefined nodes -
the type of nodes that are matched by a traditional wildcard.
One solution is to define a new RR for each security policy but this now
means that every party who deploys DKIM is obliged to upgrade their DNS
servers, the dependency on infrastructure deployment is two sided not
unilateral. This type of infrastructure change typically take ten years
or more.
A much better solution is to make a much more limited dependency, one
where the only parties that are required to upgrade their DNS servers
are the ones who are going to take advantage of the new wildcard
handling to simplify administration. In other words the person who does
the work gets the benefit.
The way to achieve this is to define one new RR that is a pointer record
to a place where the security policy records for that node can be found.
So for example we have:
*.example.com XXX _defaultpolicy.example.com
_domainkey._defaultpolicy.example.com TXT "stuff"
_emailencryption._defaultpolicy.example.com TXT "stuff"
_inch._defaultpolicy.example.com TXT "stuff"
We have now turned the DNS into an entirely general purpose policy
publication and distribution infrastructure. It is not necessary to
specify any new RRs to add in new security policies. It is not necessary
for FUTURE security policies to wait ten years for adoption.
The other benefits of this scheme is that we have created a significant
incentive for DNS admins to upgrade to DNSEXT without creating a
dependency< on support for publication of new records. We create a
strong incentive for an O/S platform vendor based in, say Redmond WA to
add these features into their new release but we do not disenfranchise
and render obsolete their entire installed base.
There is a small dependency on deployed DNS infrastructure being capable
of transmitting these records. I don't think that this is a crippling
disadvantage since the proportion of DNS infrastructure capable of
transmitting new DNS records is much greater and we are not proposing to
take this mechanism to the client end of the communication immediately.
There is another significant benefit of this mechanism. Since it applies
to ALL prefixed records security policies can now be grouped together
and managed as a unit. So we might have different profiles for different
types of machines. Instead of writing these out for each machine
separately we simply put the appropriate pointer in place. We get a much
more granular expression capability.
If DNSSEC is deployed the pointer records provide even more value. They
allow the maintainer of a large domain (e.g. mit.edu) to significantly
reduce the number of policy records they need to publish.
Some people have argued that the only 'PROPER' way to extend DNS is by
deploying new RRs and that a TXT structured record is somehow deficient.
I think that approach is very short sighted. In the first place there
are simply not enough DNS RR code points to support that approach since
every protocol should really be publishing security policy.
The SRV prefix mechanism is logically superior to the traditional port
based assignment. It is far more expressive, far more flexible. It
allows for a much superior separation of the naming infrastructure and
the IP addressing infrastructure. The prefix mechanism is clearly the
future of the Internet and not assignment of a dwindling supply of
unique port numbers.
The RR code is logically a syntax declaration. The SRV prefix defines
the specific protocol semantics. The XXX pointer record provides
management capabilities and completes the management features.
Doing it this way creates a much more attractive set of deployment
incentives and avoids the double ended deployment dependency catch-22
that has delayed deployment of DNSSEC for over a decade.