Re: [art] draft-ietf-dnsop-attrleaf

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Adam Roach writes:
> 
> On 7/28/17 1:30 PM, John Levine wrote:
> >> ... and then create two additional sub-tables (one for "_tcp"
> >> and one for "_udp"), which register all the "_service" types that can
> >> appear under these two "_proto" types
> > Please, no.  That registry has existed for decades and has upward of
> > 10,000 entries.  See RFC 6335 and:
> >
> >   https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numb
> ers.xhtml
> >
> > I agree that service names that appear in the registry do not belong in attrleaf.
> 
> 
> Ah, yes. I'd missed that the intention of RFC2782 was to allow SRV 
> records to be instantly usable for all registered services, rather than 
> having each service defining specific additional procedures for SRV 
> resolution. (For example, RFC3263 defines some specific rules around 
> handling priorities across different transports, which goes beyond the 
> handling described by RFC2782). On review, your interpretation appears 
> to be correct.
> 
> In that case, it would appear that the main action here would be to 
> clean up the SRV entries in Table 1 -- by my understanding, the way 
> RFC2782 is written, the only registered SRV entries in the registry this 
> document establishes should consist of some strict subset of 
> <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml>.
> 
> /a

SRV records are ONLY to be use for protocols that specify that they
be looked up.  There are generic proceedures for how to select a
server given that SRV records are permitted in the first place.

RFC2782

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.

This was written this way so that existing protocols like SMTP, DNS, and
HTTP didn't just suddenly sprout SRV "support".

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]