Jared Mauch wrote:
And it can be automated if browsers support SRV, a DNS RR type to
specify non-default port numbers.
I'm not talking about a browser.
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.
I'm talking about ALG that actively breaks things or exposes
the end devices to increased attack surfaces due to devices that will
never be properly maintained or are impossible to report defects against.
And using non default port numbers is the solution, for which SRV
and applications supporting SRV should be helpful.
I look at the work in DNSOP to document that queries over
TCP are acceptable, but you end up with devices where they will never
be upgraded and do this:
The problem here is that a port number is implied by NS (and MX)
as I wrote in https://tools.ietf.org/html/draft-ohta-e2e-nat-00:
A server port number different from well known ones may be specified
through mechanisms to specify an address of the server, which is the
case of URLs. However, port numbers for DNS and SMTP are, in general,
implicitly assumed by DNS and are not changeable.
Still, in theory, SRV could be specified to override MX like:
example.com MX 0 mx.example.com
_mx._tcp.mx.example.com SRV 0 0 1000 mx0.example.com
and NS (often with glue As and glue SRVs) like:
example.com NS ns.example.com
_ns._udp.ns.example.com SRV 0 0 1000 ns0.example.com
_ns._tcp.ns.example.com SRV 0 0 1000 ns0.example.com
ns0.example.com A 192.0.2.1
Even in practice, as changes can be fully backward compatible
without any flag days, it is doable as a long term solution
against poor ALGs.
Masataka Ohta