Re: [tae] New draft: announcing the supported transports via DNS

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]] 
> Sent: Tuesday, October 06, 2009 9:51 AM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tae] New draft: announcing the supported 
> transports via DNS
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> ...
> >> > There are numerous applications that use reverse DNS for 
> verification,
> >> > e.g., HTTP name-based access, SSL, etc. Users don't have 
> control over
> >> > reverse DNS.
> > 
> > Agreed.
> > 
> > But how is reverse DNS authentication relevant to selection of 
> > a transport protocol?
> 
> If all you have is an IP address (whether the user types it 
> in or it is
> provided in-band), the only thing you can lookup in the DNS 
> (to find the
> supported transports for that address) is reverse DNS.

Our proposal, draft-yourtchenko-tran-announce-dns-00, does
not suggest looking up PTR records.

We're trying to optimize the Happy Eyeballs probing
(draft-wing-http-new-tech-00) for the 99.65% of websites
that have DNS names.  99.65% comes from Alexa's list of
top 1,000,000 websites; 3455 of them are IPv4 address
literals.

-d

> ...
> >> > First, the DNS is not always available or desirable.
> >> > 
> >> > Second, if you solve this for the DNS, you can use a 
> similar solution
> >> > directly between the endpoints without involving the DNS.
> >> >
> >> > Third, if you force all endpoints to support a default 
> >> > transport to talk
> >> > to the DNS, you have a default transport to talk to all other 
> >> > endpoints anyway.
> > 
> > I sure would like to see your straw man proposal, because I
> > cannot fathom how you would accomplish this feat.
> 
> First, I don't need to provide a strawman to express concerns with an
> existing proposal. We aren't picking a place for lunch*.
> 
> Second, I'm basically suggesting that this all boils down to the need
> for a transport negotiation protocol between the endpoints. There are
> numerous challenges to designing an effective negotiation protocol:
> 
> 	- latency to detect supported protocols
> 	- latency to fallback if not supported
> 	- interaction with NATs/firewalls
> 
> Just saying "use the DNS" doesn't solve these problems any better than
> "build a new exchange protocol", and adds other problems:
> 
> 	- support for non-DNS endpoints (IP address specified)
> 	- involvement of a third party (lack of fate-sharing)
> 
> Joe
> 
> *(typical lunch location negotiation rules are "if you shoot down a
> proposed site, you must counter with an alternative you are willing to
> accept")
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAkrLdYsACgkQE5f5cImnZrvsjwCg5P6SGGzdxBwr2FtPr2aSPS/k
> Fa0AnjEmKD99tDni7QysjTpPDAeC/B4Z
> =+SUt
> -----END PGP SIGNATURE-----