Saku Ytti wrote:
Sorry, browser is just an example and any application using domain
names can support SRV to avoid default port numbers contaminated by
ALGs. See below for examples of mail and name applications.
Friends of SRV should read
https://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr-01
The problem of SRV-like proposals is that they have too much
features not needed by most applications, among which, SRV is
least painful.
If I design a new RR, it would be:
_<port>._<proto>.<domain> REDIRECT <altdomain> <altport>
where <port> and <proto> are in decimal.
a) if we add SRV to browsers, we need to do +3 DNS lookup per resource
'for ever',
With
example.com MX 0 mx.example.com
_mx._tcp.mx.example.com SRV 0 0 1000 mx0.example.com
only one DNS lookup is enough by answers with additional
records, which can be safely cached.
SRVINFO will allow for 1 ultimately.
From an implementer's point of view, fancy fields of <InstanceId>
and <Profile> are enough to abandon SRVINFO and URI is worse than
that because most applications can not treat most fields of
generic URIs.
b) it can announce all the transport protocols you're supporting
Yes, all the transport protocols and all the services of a domain,
which are announced by SRVINFO RR of the domain.
That is a fatal defect of SRVINFO (and URI), because, if a domain
support 100 services with 2 transport protocols, there are 200
RRs, all of which must be replied for a single query, which is
unacceptably inefficient, which is why it is necessary to use a
service specific domain name for each service.
All the applications know which service they are offering and
almost all, if not all, applications including DNS, know which
transport protocol they are currently trying to use.
Masataka Ohta