I think this is a fine proposal. However, I would draw your attention to a couple of points. 1) What you are proposing is the ability to dynamically change a client's IP address. This is probably useful for mobility scenarios but I don't see where its really buying you much over current systems. I mean, if I want to signal you directly for a VoIP call (for instance), I can do that now as long as your IP address is static and in regular DNS. So in that sense, there's some additional benefit but it begs the second point... 2) In addition to location which is assisted by the proposal you are making, what is really needed is identity. That is, how do I know that David Barrett can be found at dbarrett.qunithar.com? That is the key problem that the P2P group should be focusing on. Regular SIP solves that problem with registrations to registrars that can be queried to route signaling. The P2P SIP group (for example) should be focusing on new ways to distribute the identity service. Thanks, FM -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barrett Sent: Sunday, September 09, 2007 9:06 PM To: 'theory and practice of decentralized computer networks' Subject: [p2p-hackers] Dynamic DNS as rendezvous service So we've 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, that's precisely what it's designed for). However, it falls down in the presence of NATs, especially restricted or symmetric NATs. But I'm 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 we're on the internet, my dynamic DNS provider responds to you o If we're 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, it'll work some of the time: o If I'm not behind a NAT or firewall, then you can connect to me directly o Likewise, if we're on the same LAN (even if it's ad hoc), my client will hear your mDNS broadcast for "dbarrett.quinthar.com" and will respond accordingly - But if we're separated by a NAT you can't connect to me because: o You don't know what port I'm 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: - Doesn't 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 I'm 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, we'd need to do the same for our VoIP protocol). This isn't 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 aren't looking for these TXT records won't need them. But if you can't listen on a well-known port (or are behind a NAT, clients can use the TXT records to figure out which port you're on. And clients that aren't 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 don't expect the extra TXT fields will simply ignore them. Existing dynamic DNS clients that don't provide port information just won't 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
