I've often wondered why more decentralized apps didn't just include BIND and provide their users with their own ability to provide dynamic DNS functions to others. I always thought an app that did that would really be the right one for cluing in and empowering masses of Internet users.
Does that make sense? Seth > David Barrett wrote: > > So weve talked a lot about how dynamic DNS / mDNS could be used in > a P2P system as the backbone of a global naming system (after all, > thats precisely what its designed for). However, it falls down in > the presence of NATs, especially restricted or symmetric NATs. But > Im wondering if there are a couple minor extensions we could make > to get around that restriction. > > > > First, as background, the basic plan is this: > > > > - I install some P2P client (eg, a VoIP client) > > - I buy a DNS name (eg, quinthar.com) from any > dynamic-DNS provider (eg, DynDNS) > > - I enter my desired user name into the client (eg, > dbarrett.quinthar.com) > > - My client uses STUN and figures out my LAN and NAT IP > addresses > > - My client registers my current IPs with my dynamic-DNS > provider > > - My client listens for mDNS resolutions on > dbarrett.quinthar.com > > - You run some P2P client > > - You type my name (dbarrett.quinthar.com) in > > - Your client does a 100% standard DNS resolution on my > name > > o If were on the internet, my dynamic DNS provider responds > to you > > o If were on an ad-hoc LAN, my client responds to you via > mDNS > > - Either way, your client gets my latest LAN/NAT IP > addresses and tries to connect in parallel > > - Now, itll work some of the time: > > o If Im not behind a NAT or firewall, then you can connect > to me directly > > o Likewise, if were on the same LAN (even if its ad hoc), > my client will hear your mDNS broadcast for dbarrett.quinthar.com > and will respond accordingly > > - But if were separated by a NAT you cant connect to me > because: > > o You dont know what port Im listening on > > o Even if you did, I probably have a restricted-cone NAT that > blocks you > > > > So first, before proposing my solution, let me rant on why this > would be so awesome: > > > > - Doesnt require inventing new protocols from scratch > > - Works both on and off the internet > > - Seamlessly supports static and dynamic IP addresses > (fixed and mobile VoIP) > > - Leverages an existing, proven backbone (the global DNS > network) > > - Is decentralized in the way that matters most: between > separate legal entities (dynamic DNS providers) across separate > international jurisdictions > > > > But, currently, the above system has the following problems, to each > of which I propose a solution: > > > > 1) Problem: When you resolve my domain name > (dbarrett.quinthar.com) you get back my IPs, but not which port Im > listening on. Thus it only works if we agree a priori on which port > to use (much like HTTP has reserved port 80 from the IANA, wed need > to do the same for our VoIP protocol). This isnt so bad, but > completely screws up any sort of port-hopping approach, as well as > any port-mapping applied by a NAT. > Solution: When my client uploads its latest IP addresses to the > dynamic DNS provider, it also provides the port being used on each > IP address. Then the dynamic-DNS provider creates a TXT record for > each IP listing which port to use. So, clients attempt to listen on > a well-known port, and clients who arent looking for these TXT > records wont need them. But if you cant listen on a well-known > port (or are behind a NAT, clients can use the TXT records to figure > out which port youre on. And clients that arent expecting the TXT > records will simply ignore them. > > 2) Problem: If behind a restricted-cone NAT, even knowing my > IP and port is insufficient to connect to me I also need to be > connecting to you at the same time. > Solution: This solution is broken into three sub-parts: > > a. When my client uploads its IP/ports to the dynamic DNS > provider, it maintains a persistent TCP connection such that the > server can communicate back to the client at any time. > > b. Rather than resolving my domain (dbarrett.quinthar.com), you > actually resolve a subdomain that encodes your own IP addresses and > ports. This communicates to my dynamic DNS provider your IP address > and port without requiring any changes to the DNS protocol, or any > DNS stack implementations > > xxx.yyy.zzz.www.port.dbarrett.quinthar.com > > c. Bringing these together: when you resolve my domain using > an encoded IP:port backchannel, my dynamic DNS provider notifies > me via the persistent TCP connection, basically saying hey, > somebody at xxx.yyy.zzz.www:port just resolved your name; you might > want to try to connect to it so he can get through your NAT. > > > > So this requires two changes to the dynamic-DNS server: > > > > 1) Record a port mapping for each IP address and respond to > DNS resolutions with a TXT record for each > > 2) Maintain a persistent TCP connection with the dynamic-DNS > client in order to notify it when people try to resolve its address. > > > > Both of these changes are fully backwards compatible. Existing DNS > clients that dont expect the extra TXT fields will simply ignore > them. Existing dynamic DNS clients that dont provide port > information just wont get the TXT fields. Likewise, if they close > the resulting TCP connection, no problem. > > > > However, with these changes, you can use the regular DNS/mDNS > infrastructure as a massive, legally-decentralized, > technically-distributed rendezvous service that seamlessly works > both on and off the internet, and seamlessly supports both fixed and > dynamic DNS names and IP addresses. > > > > Where are the holes? > > > > -david > > -------------------------------------------------------------- > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers -- RIAA is the RISK! Our NET is P2P! http://www.nyfairuse.org/action/ftc DRM is Theft! We are the Stakeholders! New Yorkers for Fair Use http://www.nyfairuse.org [CC] Counter-copyright: http://realmeasures.dyndns.org/cc I reserve no rights restricting copying, modification or distribution of this incidentally recorded communication. Original authorship should be attributed reasonably, but only so far as such an expectation might hold for usual practice in ordinary social discourse to which one holds no claim of exclusive rights. _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
