FYI: Joe Abley reminded me off-list that the service name for DNS is "domain", so my suggestion for the name for this new assignment would then be "domain-s".
Note: there have been several types of suffixes to indicate security: -ssl, -tls, -sec, and more recently -s. Because there are many types of security and to allow more characters for the remainder of the service name, the -s suffix is currently preferred by the IANA Ports Review team. Joe On 8/11/2015 11:00 AM, Joe Touch wrote: > > > On 8/7/2015 6:03 AM, Warren Kumari wrote: >> Hi all, >> >> The chairs believe that there is sufficient interest in the working >> group for early allocation of a port for dns over TLS, following RFC >> 7120. > > Hi, Warren, > > It might be useful to summarize on this list the rationale for this > allocation and the plan for its use. > > In particular: > > - why port 53 is not sufficient using STARTTLS > > - why a system port, rather than a user port, is appropriate > > - whether TLS-protected DNS would ever be expected on port 53 > > Speaking as an individual (though I also chair the IANA port expert > review team, which reviews applications not through the standards > process), my view is that: > > a) it would have been preferable to use the existing > assigned port for DNS (e.g., using STARTTLS), as I note > in RFC7605 > > b) the existing ubiquity of DNS ALGs will make (a) difficult > (this does not apply to new protocols but would here) > > c) if the secure variant has a separate port, then it would > be confusing to run the same service on multiple ports > > d) if this service is assigned a new port, it should be > a system port; although system ports do not often afford > the protections once assumed, it seems reasonable to stay > with the same type of port as the original service > > As a result, I concur with the assignment of a port for "dns-s" (FWIW, > that's what I would suggest, as it is the convention for most new secure > variants) as a system port. > > Joe > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
