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