Re: Something better than DNS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]