Since the issue here seems to be precedent it seems more productive to discuss
the choices draft. If people actually read choices they will realize that DKIM
complies with the findings of fact there.
Since 1) choices is not an RFC 2) the DKIM group have had extensive discussions
with the DNS directorate and the choices draft author it seems to me that the
effort in this forum would be better directed at examining choices and ask if
this really reflects the best way to achieve everyone's goals.
In particular there are architectural approaches proposed after the initial
choices draft that have been raised with the editor of the draft and in DNSEXT
that are not addressed in the draft.
From: Michael(_dot_)Dillon(_at_)btradianz(_dot_)com
[mailto:Michael(_dot_)Dillon(_at_)btradianz(_dot_)com]
In fact, the issue of port 53 services being such an
important infrastructure leads me to think that the IETF
should freeze the DNS protocol definition for anything that
is not directly related to the job that port 53 servers MUST
do. Things like DNSSEC are OK, but leveraging DNS for a
global distributed database are not.
Read the original discussions of SMTP that led to the development of DNS. You
will find that the proposed use is entirely within the original scope that Jon
Postel anticipated.
DNS was originally designed to be multi-protocol and multi-network. That's why
the class mechanism exists to support Heisod and CHAOS.
The lack of protocol meta-data is a major reason for the difficulty of changing
IETF protocols. The SRV record is a great leap forward, it would be even better
if people actually used it to advertise their POP3, SUBMIT and IMAP services.
Since there is great interest in using the DNS protocol for a
distributed database, it would help to fork the DNS protocol
and deal with this work in a separate WG and using a separate
port number.
There is already a revolt underway and people are using the DNS to distribute
policy. One approach is to say 'we know best, la-la-la not listening'. A better
approach that is more likely to have the desired effect is to define a protocol
that meets these peoples needs.
A second reason I intensely dislike this approach is that the DNS should be the
one and only authoritative source for resolving information bound to a DNS name
in the Internet class. There must be a single point of administration.
A much better approach would be to specify a limited mechanism for distributing
policy through the DNS. This would have two levels:
1) A very limited sequence of tag=value pairs to be used to encode the simplest
forms of policy statement 'This sender always uses S/MIME', 'This sender always
uses DKIM'.
2) A defined tag value that specifies a URI where a comprehensive XML encoded
policy can be found.
The reason for the two levels is that there are many useful protocol policy
statements that are very simple and can be encoded in a very short response. It
seems unnecessary to force people to pull a http URL out of the DNS and then
extract a statement like 'DKIM' or 'STARTLS=TRUE' ot
'LDAP=ldap.example.com:2234'.
We do not need to define a directory infrastructure to support the second
level, URLs will do just fine. We use the DNS to provide the authoritative
resolution protocol.
Now lets consider the issues raised in CHOICES carefully
Choices gives four options of which only two are viable:
1) Use a prefix record in the same manner as SRV and NAPTR
To make this approach work we have to consider the prefix record as
being in a sense a modifier to the semantics of the record being prefixed. So
_DKIM.example.com TXT has its syntax defined by the DNS protocols and its
semantics defined by the prefix.
The disadvantage of prefix records is that it is not possible to define
a wildcard of the form _prefix.*.example.com. So if an application requires the
ability to make a default statement prefix records do not work without
additional mechanism
2) Define a new RR
This approach works so long as the deployed DNS infrastructure at the
sender and receiver and all relays inbetween all support exchange of unknown
record types.
Wildcards work with a new RR ith the proviso that the wildcard
semantics of DNS are not necessarily the semantics that the administrator would
want. A wildcard only matches non-existant nodes. So some form of preprocessor
is going to be required to define a default policy record that applies to every
node in a zone.
The disadvantage with this approach is that there are only 65,536
possible RRs. This is not currently a problem but is almost certain to become a
problem if every protocol and every new Web Service requires a policy record.
Now lets consider the essential goals that parties might want to achieve:
1) Deployment of DNSSEC
This is dependent on the ability to deploy new RRs.
2) Deployment of DKIM base
This does not need the ability to specify default keys and thus does
not require wildcards
3) Deployment of DKIM policy
This does require the ability to specify default policy and thus
requires wildcards
4) Support for general extensibility of the DNS
5) Ensure general extensibility of the DNS does not lead to collapse of the DNS
The last is critical of course but in a sense the DNS collapsed five years ago.
It only operates today because a vast sum has been spent ($200 million+)
keeping it running. The load on the core DNS is not caused by legitimate use.
The load comes from misconfigured DNS systems and malicious attacks. The
legitimate load is barely measurable. It is a major mistake to think that the
DNS is so fragile that it can't be used to good purpose.
We do however have a legitimate concern that goals 4 and 5 are potentially at
odds. I don't think that the proposal made in CHOICES is optimal, that is I
don't think that 'create a new RR for every use but establish a mechanism for
vetting proposed uses' is optimal. The problem is that every RR that you add is
a change to the DNS infrastructure, another opportunity for someone somewhere
to mess up.
The approach that CHOICES does not address is to solve the wildcard prefixing
problem by introducing a new record that acts as a pointer, the Prefix Pointer
record: PREPTR.
To encode the wildcard record _prefix.*.example.com we create the following
records:
*.example.com PREPTR _preptr.example.com
_prefix._preptr.example.com TXT "This is the default record"
This has all the advantages of defining a new RR. Wildcards work, it is not
necessary to define a new RR for every single protocol that might want a policy
statement. All that is required to put out a policy statement is an IANA
registered prefix.
[In actual fact the PTR record could almost certainly be used for this purpose
but introducing a new record has political benefits and creates a useful
deployment incentive for DNS servers that support new records.]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf