Re: Something better than DNS?

> > 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf