DNS is getting very long in the tooth, and is entirely too inflexible
and too fragile. The very fact that we're having a discussion about
whether it makes more sense to add a new RR type or use TXT records
with DKIM is a clear indicator that something seriously is wrong with
DNS. Adding a new RR type should not require a single line of DNS
server or client library code to be recompiled, nor any changes to the
configuration of any server not advertising such records.
Keith,
I've seen you say this for many years now, but I'll bite now.
Do you have ideas what a more flexible, less fragile, and in general a
better mechanism would:
1) be or look like, or
2) what requirements we should have for building and deploying it?
(if such a thing or a close likeness doesn't exist)
I wonder if there are practical alternatives. A bit more dialogue on
"what else" instead of "DNS is a bad idea" might help in figuring out
whether there is anything the IETF could do about it.
here's the background: starting about 12 years ago I designed and coded
up a system called RCDS which was designed to keep track of replicas of
web-accessible resources. part of this system was a thing called the
resource catalog, or RC for short. the idea behind RC was that
authorized parties could use it to store information about a URI. it
was federated and replicated like DNS, but the keys were in URI space
rather than domain space. this was before NAPTR and SRV records were
formalized but the intent was to use something like NAPTR records to
parse URIs and to use SRV records to find the RC servers for a
particular URI.
RC was developed in response to suggestions that we store all of the
metadata about a URI in DNS. this would have been a real mess for lots
of reasons - partially because DNS wasn't designed to key on URIs,
partially because we needed a lot more extensibility in the equivalent
of RR types than DNS could ever do, partially because we needed a
different consistency and caching model, partially because we needed
more flexibility in "additional information" handling, partially because
we needed to be able to have different RRs be updated by different
parties at different times and yet still have signatures over multiple
RRs signed by those different parties.
so anyway I came up with some ideas about how to solve those problems,
designed a protocol, implemented a RC client and server, and used it to
keep track of web replicas. and then I realized that it didn't have to
just be used for web replicas, but could keep track of metadata about
anything that could be named with a URI. so I designed a distributed
computing system called SNIPE that used RC to keep track of information
about processes - e.g. process locations (processes could migrate),
process status, and communications channels that could be used to
contact those processes.
and then I realized that it would be possible to encode DNS RRs in RC in
a lossless way so that the original DNS-format RRs could be recovered,
and DNSSEC signatures could still be verified. and that convinced me
that there could be a transition path from DNS to something else - e.g.
a single server could support queries for both DNS and RC protocols from
a single backing store, and perhaps even handle DNS dynamic update in
addition to RC update. new apps that wanted to make use of the
increased flexibility of RC would use the RC query and/or update
protocol, legacy apps would probably continue to use DNS because it
would be supported by more zones.
I'm not saying that RC would be a great drop-in replacement for DNS, as
it was just a prototype and several of its ideas were never tested
extensively to see whether they were as useful as I thought they would
be. but the experience with RC convinced me that DNS could be replaced
with something much more flexible and still have an orderly transition,
and that this could be used as a way to fix a lot of the longstanding
problems with DNS. assuming, of course, that second-system effect could
be avoided.
Keith
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf