Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Mar 1, 2016 at 11:59 AM, Ray Bellis <[e-mail]> 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.