[p2p-sip] what's wrong with DNS?

hsinnrei at adobe.com (Henry Sinnreich) Tue, 21 November 2006 16:29 UTC

From: "hsinnrei at adobe.com"
Date: Tue, 21 Nov 2006 08:29:44 -0800
Subject: [p2p-sip] what's wrong with DNS?
In-Reply-To: <1fc32c8f0611201914pcba511bka99ecbdaa65136b@mail.gmail.com>
Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22141344@namail5.corp.adobe.com>

I agree with Michael. 

Research folks are reporting on why and how to replace the DNS. 
Here is some good weekend reading to start with :-)

http://www.acm.org/sigs/sigcomm/sigcomm2004/papers/p292-ramasubramanian1
111.pdf 

After homework - reading this paper, we can formulate something better
for p2p bootstrap.

Thanks, Henry

-----Original Message-----
From: Michael Slavitch [mailto:slavitch at gmail.com] 
Sent: Monday, November 20, 2006 9:14 PM
To: Saikat Guha
Cc: Henry Sinnreich; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] what's wrong with DNS?

DNS was designed in the days when long-term store was scarce and so
was bandwidth. Technology was difficult and obtuse, with the number of
human implementors measured in the hundreds, and the number of users
in the thousands. I remember that because I was there. There was no
other way to pass this data. Something had to be first and that was
DNS, which reflected the times and the organizations that invented it
in the first place.

Those days are long gone now in the days of the $20 grocery-store 2G
flash RAM, millions of implementors, and billions of users.

Today's Internet is a consumer-driven multi-modal world which has no
patience for that.
To cripple bootstrap by leashing it to creaky DNS is a disservice to
the future.

Bootstrap should have some criteria requirements for some obvious
things such as satisfying the security AD but the actual
implementation should allow for individual implementations that
reflect a rapidly changing modern world.

Hardcoding is a quaint way of solving the problem, and it is far too
easy for protocol engineers to design in a vacuum. When a single
handheld device can receive inputs by SMS, email, walled and unwalled
IP,  and HTTP the number of sources for a bootstrap is openended and
impossible to mandate without creating limitations on functionality
and usefulness in a hybridized multi-modal world..

A mime message, encrypted by a private key known to that device, could
contain a myriad number of bootstraps, be they DNS, hardcoded IP (IPV4
or IPV6? Which?), local names,  peer names, SMS addresses,sip uris,
whathaveyou.  A list based on operating criteria, that can evolve over
time.

This message, more 'carrier pigeon'  than boostrap, can be delivered
via a variety of means, including via C/S SIP or stored from a
previous DHT. A primitive form of unencrypted messaging is called
'paper'.

In this environment a 'friend' network, of names associated with keys,
could be seeded entirely by SMS messages and never ever need DNS,, and
it works when zeroconf fails, which is often.  It could later use
broadcasts or multicasts to find other 'friends', using one of a
variety of techniques, zeroconf being one.

Create the requirements for the bootstrap that guarantee security,
functionality and interopability.  Create the list of appropriate
beacons, allowing room for more in the future.

Then stop, please.



On 11/20/06, Saikat Guha <saikat at cs.cornell.edu> wrote:
> On Mon, 2006-11-20 at 16:19 -0800, Henry Sinnreich wrote:
> > >except it would use dynamic DNS instead of a DHT
> >
> > P2P overlays are supposed to work even when disconnected from the
big
> > Internet and besides, have their own name space.
>
> Even P2P overlays need some way to bootstrap in disconnected networks.
> While DNS _typically_ bootstraps with hardcoded IP addresses of the 13
> root servers, it can bootstrap in a disconnected scenario with a link
> level broadcast. See Apple's rendezvous/zero-conf protocol and mDNS.
>
>
> --
> Saikat
>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>
>
>