- From: Mark Jeftovic <
>
- To: ProjectVRM list <
>
- Subject: [projectvrm] The role of DNS in VRM
- Date: Mon, 10 Sep 2012 21:56:40 -0400
- Organization: easyDNS Technologies Inc.
I'm new to the list and this is a first post, I hope I don't embarrass
myself...
I became very excited when I started reading The Intention Economy
because it put words around the direction I think we've been trying to
go for awhile now. (In fact our mission statement since 1998 has been
"to drive a stake through the heart of 'lock-in' in all it's forms")
It probably started in earnest for us when Amazon entered our market
with their Route53 DNS offering and for some reason our instinctive
reaction was to make friends with it rather than compete. We built
full-on integration with it so that people could use our UI to manage
their zones on Route53 (at the time there was no Amazon UI) - and to
distribute their DNS zones across both systems, using either side as the
"primary" and the other side as the "secondary" or "mirror".
That got us starting to think about facilitating access to more third
party systems, so instead of locking people in to our own DNS cloud,
we'd encourage people to spread their DNS across multiple providers
(like the root servers do).
I am thinking of this as very baby steps in a "proto-VRM" system for DNS.
Now I'm about 2/3 through the book (and very early into the Live Web
book) and it occurs to me that the DNS protocol itself could be a
natural enabler for VRM itself - because it has many of the attributes
of VRM tools.
In much the same way DNS was extended without the addition of additional
RR's to facilitate Sender Policy Framework (SPF) (done via creating
specially designed TXT records) - VRM information can be conveyed via
the DNS:
TXT records could be defined which transmit personal intentions such as:
- an RFP for services. It could contain stub data about the
service/product required and a pointer to an XML document with further
details
- identity references (already closely tied to DNS via protocols like
openid) but you could use DNS pointers to allow vendors to differentiate
between various roles you assume (CTO, dad, chess partner, bass player,
etc) and where that data is served from.
- setting terms / policies / preferences: again with stub data to denote
what it pertains to with pointers to external documents
The list goes on.
In fact......(sorry, at this point of thinking it through I got really
excited)
Many of you are probably aware of the "new Top Level Domain" craze
originating out of ICANN. I have been a skeptic of this initiative from
the beginning - not because I'm against opening up the namespace, I'm
not - but because of the myopic approach to every new TLD application
I've seen, which fits in one of the following silos:
- competing with .com (*yawn*)
- .brand (*yawn*)
- .vertical (because every lawyer will sign up for a .law
domain...simply by virtue that it is called ".law")
I've blogged about this at length in various places, and what I usually
lament is the absence of any real innovation of raison d'etre for any
new TLD. Somebody think outside the box please!
Well VRM could be that case. You could create an entire namespace that
exists to transmit personal preferences, intentions and requests.
(When I try to think of a "good reason" for a new TLD to exist, I try to
think of cases where typing the new domain into a web browser is
essentially pointless, this may be it).
So I would use say, markjr.vrm to broadcast my RFPs, openid's, public
keys. etc and I could manage it all from any DNS server in the world (of
course there are many choices already to manage DNS - if something like
this happened, we would see more).
Granted, it wouldn't *have* to be a TLD like .vrm, you could use
anything: vrm.markjr.net, or markjr.easydns.com - and broadcast the
presence of VRM data with a specifically crafted TXT or SRV record.
If it evolved, additional RR's may be added to the DNS spec (as with the
aforementioned SPF data, when the SPF RR type was added).
Then if it *really* evolved, to the point where not only additional RR's
were proposed and added, but that nameservers themselves were enhanced
to modify the way they query RR's with VRM data present *then* having a
.vrm TLD may make even more sense.
Ok, that's probably enough for now. Sorry if this has been a long first
post, but I'm pretty enthused to come across the whole VRM movement.
I think I've been waiting / looking for this for a long time.
respecfully,
-mark
--
Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
Company Website:
http://easydns.com
Read My Blog:
http://markable.com
+1-416-535-8672 ext 225
- [projectvrm] The role of DNS in VRM, Mark Jeftovic, 09/10/2012
Archive powered by MHonArc 2.6.19.