I posted this in response to the MARID convulsions but it is also
relevant here. The bottom line is that we absolutely do not need a new
DNS RR at all. We can achieve what we want to achieve using prefixed
records and a minor change to the resolution protocol. The only changes
that are needed to legacy DNS servers is possibly to require use of a
macro-processor to expand synthetic wildcards.
Since the main reason people are pushing for a new RR requirement it is
important to note that this mechanism does create a significant upgrade
incentive without actually rendering the DNS server obsolete.
I think the damands are misguided. Deployment dependencies are very very
bad for both sides. It is much better to create a situation where DKIM
can be deployed at full speed and DKIM deployers are strongly encouraged
to deploy DNSEXT upgrades than to make DKIM dependent on the upgrades.
It is much better to have a strong tie to a protocol growing at 20%
quarter on quarter than to create a dependency that slows growth to 5%
quarter on quarter. 25% of a market growing 20% quarter on quarter is
infinitely better than 100% of a stagnant market.
All that matters is to get to critical mass, once DNSSEC gains a certain
marketshare growth will become self-sustaining.
==The Scheme==
The first step is to address the problem that wildcards do not match an
existing node. As was demonstrated on the list this is easily solved
using a macro processor.
The second step is how to create a wildcard for _prefix.*.example.com
without changing legacy DNS servers.
The way to do this is to introduce a pointer record using CNAME as
follows:
_prefix.exists.example.com TXT "Policy1"
*.example.com CNAME _wildcard.example.com
_prefix._wildcard.example.com TXT "Policy2"
The resolution algorithm for domain X is:
1) Check for a TXT record for _prefix.X if it exists, return the TXT
string and stop
2) Check for a CNAME at X, if it does not exist return 'NIL' and stop
3) Check for a TXT record for _prefix.Y where Y is the CNAME mapping. If
it exists return the TXT string, otherwise stop.
Applying these rules to the scheme above we get:
Lookup ("exists.example.com", "prefix") = "Policy1" [cost 1 lookup]
Lookup ("empty.example.com", "prefix") = "Policy2" [cost 3 lookups]
Lookup ("empty.example.com", "noprefix") = NIL [cost 3 lookups]
This algorithm is 100% compatible with the deployed, legacy DNS and
meets all use cases that were proposed for wildcarding. It never takes
more than three DNS lookups. The first two can be requested in parallel,
an intelligent DNS server could return the CNAME as an additional record
for optimization purposes.
If this mechanism was adopted as policy for ALL prefixed records there
would no longer be any need to define new RRs unless there was a need to
define a new record syntax. It would also allow admins to manage their
policy records much more effectively, the default node is treated as if
it was just another node.
==Upgrade Incentives==
===Admin Convenience===
Butler Lampson (inventor of ACLS) once told me that there should only
ever be one instance of an ACL. Instead of applying ACLs to every file
in a directory the ACL itself should be created exactly once and the
each file should have a pointer to the ACL.
We should do the same thing here, who was it that said all you need to
solve any problem in Comp Sci is an extra level of indirection?
Imagine that our network admin is administering a very large network,
there are three types of machine, personal machines, general purpose
servers and mail servers. Each has a different set of policy statements
associated with it.
Synthetic widlcards do not really address this problem. What the network
admin is most likely to do is to define a synthetic wildcard
_prefix.?.example.com to define the policy for the personal machines and
then confugure policy for each server individually.
What the admin really needs is a way to express policy for each group of
machines, similar to the pointer mechanism we specified for wildcards.
Of course we can do this, we just define a reserved tag to use in the
zone file that will stand for the synthetic pointer.
personal1.example.com SPOINTER _personal.example.com
personal2.example.com SPOINTER _personal.example.com
personal3.example.com SPOINTER _personal.example.com
personal4.example.com SPOINTER _personal.example.com
mail1.example.com SPOINTER _mail.example.com
_prefix1._personal.example.com TXT "whatever"
_prefix2._personal.example.com TXT "whatever"
And so on.
===Zone Transfers===
The only problem with server side macro expansion is that they don't
work with zone transfers so the zone transfer file is going to get
rather large since the sender is going to have to expand out all the
macros.
But zone transfers are an area where we can add a new query type for the
unexpanded zone file without any difficulty, the zone transfers
themselves are programmed events after all.
===DNS SEC===
The final upgrade incentive is DNSSEC. If DKIM succeeds then DNSSEC
becomes a no-brainer.
I would expect any DNS server that adds the synthetic wildcard or
pointer upgrades described is also going to add DNSSEC.
_______________________________________________
ietf-dkim mailing list
http://dkim.org