Re: The End-To-End Internet (was Re: Blocking MX query)

[Owen DeLong <owen () delong com>]

On Sep 6, 2012, at 22:31 , Sean Harlow <sean () seanharlow info> wrote:

> On Sep 6, 2012, at 23:44, Valdis.Kletnieks () vt edu wrote:
>
> > However, Joe Sixpack doesn't really have that option.  And
> > unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or
> > whatever to request an SRV entry saying that the PS3 wants to do service
> > "foobar" on port 34823, you can't use SRV like that.
>
> I think you missed the point on this one.  Even if your PS3 has a public IP with no limitations on ports, how exactly 
> are others going to find it to connect to it?
>
> I see three options here:
>
> 1. You have to give them the IP address, in which case it's not exactly rocket science to give them the port as well. 
>  The same Joe Sixpack who couldn't find the port couldn't likely figure out his IP either, so the PS3 would have to 
> be able to identify its own public-facing IP and tell him, in which case it could also tell him the port.
> 2. DNS, which while many don't have this ability any that do should have no problem setting a SRV record.  Obviously 
> not all clients support the use of SRV records, but that's not the subject of this particular tangent.

Anyone can set up free DNS from a variety of providers and get a domain name for ~$10/year. I'm not sure why you think 
there is anyone who can't get DNS. If you can operate a web browser and come up with $10/year or so, you can have 
forward DNS.

The inability to influence Comcast's nameservers would only affect reverse lookups (which SRV goes forward, not reverse 
IIRC).

> 3. Intermediary directory server hosted at a known location.  Pretty much the standard solution for actual PS3 titles 
> as well as almost all other games since the late '90s.  Rather than telling the user, the PS3 tells the central 
> server its IP and port plus any useful metadata about the service being offered and the user just needs to give his 
> friend a name or other identifier to find it in the list. 

Which becomes ugly and unnecessary with full transparency and useful DNS, which we get with IPv6 even without SRV 
records. To make SRV records meaningful, OTOH, virtually every client needs an update.

> None of these options are impacted by being behind a NAT as long as they have the ability to open a port via UPnP or 
> equivalent, so if in an ideal world all client software understood SRV records this particular negative of NAT would 
> be of minimal impact.  Of course the real world is nowhere close to ideal and personally SIP phones and Jabber 
> clients are the only things I've ever observed widely using SRV records, so at least for now I can't just do 
> something like "_http._tcp.seanharlow.info 86400 IN SRV 0 5 8080 my.home.fake." and host my personal site on my home 
> server (Mozilla has had a bug open on this for over ten years, Chrome for three, and Webkit closed their bug as 
> WONTFIX two years ago so I don't expect this to change any time soon).  At this point we're coming back around to the 
> already raised point about if we're going to have to change a lot of things, why not just put that effort in to doing 
> it right with IPv6 rather than trying to keep address conservation via DNAT alive?

+1 -- Address transparency is a good thing.

Owen