On Tue, Mar 1, 2016 at 11:59 AM, Ray Bellis <r...@bellis.me.uk> wrote: > > > On 01/03/2016 16:56, John Levine wrote: > >> If you take a look at that registry, it's a stroll down memory lane. >> You'll find NVP-II from RFC 741 in 1977, PUP and XNS-IDP from Xerox in >> 1980, and other great hits from networking history. >> >> I really doubt that people are going to ever publish _pup SRV records >> other than perhaps on April 1. > > Ok, let's turn that around then - are there entries in the existing > protocol registry that _should_ be reserved in the underscore registry, > "just in case" ?
Its a bit more complicated. The _service._protocol approach in SRV is rather obviously a mistake. Given the function of SRV, the protocol tag should have been on the RIGHT hand side of the RR type, not the left. The choice of UDP or TCP should be an OUTPUT from the service discovery process, not an input. So while SRV and NAPTR and the TXT records are stuck using the two level approach, there is also a clear need for a meta-discovery record that only uses the service prefix. So lets say you were looking to find a mathematical mesh server (mmm). Using SRV discovery you might use: _mmm._tcp.example.com SRV 1 10 80 host1.example.com _mmm._tcp.example.com SRV 1 10 443 host2.example.com This is OK but its rather ugly. Does port 80 vs 443 entail the implicit use of TLS? If so what factors would determine the SSL trust anchor? What you would really want is for TLS to be a potential protocol selection like UDP vs TCP. Which is why it belongs on the right hand side: _mmm._tcp.example.com SRVR 1 10 TCP 80 host1.example.com _mmm._tcp.example.com SRVR 1 10 TLS 443 host2.example.com Sure we can write heuristics and maybe use some bits of DANE. But the result looks like an amateur hack because that is exactly what it is. Discussion of SRV discovery was verbotten in the DANE working groups by the chairs (don't blame me, I tried). And it is too late to make that work now. So if you were going to do a 'green field' discovery system using a 'New Discovery Record', you might do something like: _mmm.example.com NDR "t=tls,tcp p=http e=json r=MDFAE-7FBGM-LG5GK-JFIR6-QN4HO-7O3ZV" This is: 1) constraining the transport protocols to TCP or TLS. 2) specifying http as the presentation layer (e.g. vs COAP) 3) specifying json as the encoding (e.g. vs JSON-B or CBOR) 4) specifying that any cryptographic chain of trust must include the key with fingerprint MDFAE... A discovery mechanism using NDR would be the first request in the discovery chain. The client would then look at the service description string. That then tells the client to look for _mmm._tcp and _mmm._tls SRV records. The NDR record is deliberately free format because changing DNS servers is HARD, no really it is ridiculously hard with a ten year lag. Which is of course why we won't use a new record at all: _mmm._ndr.example.com TXT "t=tls,tcp p=http e=json r=MDFAE-7FBGM-LG5GK-JFIR6-QN4HO-7O3ZV" QED. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
