Hallam-Baker, Phillip wrote on the namedroppers list:
One issue that keeps coming up is the desire to publish some form of policy
indication through the DNS.
I don't think that the IETF can or should ignore this. If we do we will end
up with the situation that most of us like least and is the reason that
people tend to try to suppress such proposals - without success. In
particular we end up with:
* Protocols that perform 'tree walking' and other forms of heuristic policy
discovery
* DNS RRs being hijacked for other purposes (e.g. SPF use of the unprefixed
TXT record)
* A proliferation of unregistered, untracked TXT and SRV prefixes.
* People sticking large chunks of XML text into the DNS infrastructure
itself
* People propose rival infrastructures (e.g. UDDI, XRI) that attempt to
superceed the DNS.
* It is not yet happening but if we make DNS RR assignments into the
equivalent of IP port numbers we should expect to see unauthorized and
uncontrolled RR assignments becoming common.
I don't like any of the above. But from an architecture perspective I fully
expect that in the future we will see most new protocols specify some form
of policy layer. And expect the number of protocols to start to proliferate
very quickly as Web Services / Mashups / Semantic web take hold over the
next ten years.
I fully expect that the number of protocols that define policy will be of
the order of hundreds a year. I don't believe that this is compatible with
the idea that each policy record should have its own RR. If we go that route
we are committing to burn several hundred, possibly thousand RRs per year to
keep up with something that is not core to the DNS protocol. That is
something that we must also avoid.
Rather than wait for the problem to become serious I would prefer to solve
the problem now, once by anticipating it.
The solution I want to propose makes use of either one new RR or possibly
two new RRs. The objective here is to get ahead of the curve by anticipating
a very large number of needs while sticking to the core principles of DNS.
In particular:
AXIOM1 : The DNS infrastructure is the sole authortitative lookup scheme
for DNS names
COROLARY1 : If a protocol policy is bound to a DNS name the mechanism for
discovery of that policy must be mediated by the DNS.
AXIOM2 : The DNS supports lightweight queries and responses
COROLARY2 : If the policy does not fit onto a few lines of text the DNS
should return a
pointer (i.e. URI) to the results.
COROLARY3 : If the form of the query requires any parameters other than a
DNS name the
DNS result must be a pointer to a service that can handle the extended query
(e.g. SIP, LDAP, etc.)
AXIOM3 : Adding a new protocol to the Internet should not require any
change to the core Internet infrastructure, including the DNS,
nor should this require consumption of any finite resource (IP
ports, DNS RRs).
This analysis makes me believe that prefix records are the way to go. This
creates a problem however since prefix records do not work with wildcards. In
particular it is not possible to define a wildcard of the form:
_prefix.*.example.com
Which is of course exactly the type of record that the DKIM people need and
many others want.
We can solve DKIM by issuing a new RR and getting round the restrictive DNS
wildcard semantics by using an administrative wildcard of some form. We can
solve GEOPRV. OK so that is two new RRs. And two sets of synthesized data to
be created at every node in the DNS tree. That is arguably manageable.
What do we do if there are a hundred policy protocols to be dealt with, each
of which require their own administrative wildcard expansion?
**.example.com DIKMP "DKIM"
**.example.com GEOPRIVP "..."
**.example.com NEWPROT1 "..."
**.example.com NEWPROT2 "..."
...
**.example.com NEWPROT100 "..."
Each of those administrative wildcards require a record to be synthesized for
every node in our zone. Say we have 200 nodes. That means we have 20,000
synthetic records sitting around. Plus another 20,000 signatures if we are
doing DNSSEC.
A much better way to solve this problem is to introduce a pointer record into
the scheme. This allows us to create the 'midpoint wildcard' without changing
or disrupting DNSSEC. The policy discovery process then becomes:
1) Look for TXT at _policy.node.example.com
If found, return the result and terminate
2) Look for XPTR at node.example.com
If not found then return 'NOPOLICY'
3) Look for _policy.<xptr-result>
If found return the result
Else return 'NOPOLICY'
Under this scheme we still need a single administrative wildcard for the XPTR
record. But every policy scheme can make use of the same XPTR record. So in
the previous example we would only require 200+200 additional records. The
combinatorial explosion is avoided.
So far the chief objection I have received has been 'this is architecture, it
might be wrong'. Which is of course right but completely unactionable. We can
forsee a problem, we have a proposed solution. It is quite possible that the
proposed solution might not anticipate every eventuiality but this does not
seem to me to be a good argument for ignoring the problem we can forsee.
What objective criteria can be defined for the correctness of an architectural
proposal? From my point of view the approach that I take is pretty minimal,
very clean and I think it through at both the protocol level (bits on the
wire) and the API level (is it possible to encapsulate this in a fashion that
makes sense).
With this addition I believe I can support the features required in DKIM, SPF,
and anything built on WS-Policy. That may not cover everything but it does at
least get us ahead of the fire.
If I am right we avoid what could become a serious problem within a few years.
Growth in the number of Internet protocols has largely been constrained by
the fact that they have been mostly targetting human-human and human-machine
interaction.
Once we get into the detailed area of machine-machine interaction the problem
space becomes huge, much larger than OASIS, W3C, ITU and IETF combined. Worse
still expect that most of those protocols are going to be designed by people
who have no real concept of the DNS except what they learn through
administering protocols such as DKIM. For every standards track proposal there
will be tens of proposals that never make it there.
Anyway, since we are told that it is easy to get a new RR assigned I am going
to propose the XPTR RR as a standards track proposal. It has to be STANDARD,
not EXPERIMENTAL or else the DKIM working group will be unable to make use of
it.
The question then is should this be a proposal made to DNSEXT or a personal
submission or what?
Sounds like a plan for a new WG. I'd hate it if DKIM is forced to repeat old
MARID discussions. Can you explain why something in the direction of UNAPTR
won't do what you want ?
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html