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

[Mark Andrews <[e-mail]>]

In message <CAMm+LwjJ0xe2wDW98JHJfV5jV3xTeuMNguU=[e-mail]>, Phillip Hallam-Baker writes:
> 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:

Really?  We have rpm's of new versions of named supplied within
hours of ISC's public announcements of new named releases.  I'm
sure there are similar announcements for other nameserver vendors.

The *BSD's have new version in their packaging systems within days
of ISC's announcements.  Other nameservers get added to the packaging
systems just as quickly.

We ship new Windows versions with the announcements.  Windows is
actually more complicated to build so we do it.

It takes a couple of months for new types to appear as they come
out in the next maintainance release.  They used to wait for .0's
but that changed several years back now.

For those that really need it sooner there are instructions for how
to add a new type available on in the ISC Knowledge Base or you can
wait a couple of weeks for us to go through the review process and
it will be in the git repository on source.isc.org.  You can then
add it to EoL versions yourself by copying the relevent files into
place and rebuilding.  No editing required.  The build process will
find the new files and use them.

If your nameserver vendor can't supply support for new types in a
timely manner then complain to your vendor.

ISC and other nameserver vendors have automatic processes to inform
us when a new type is registered as we realise that this needs to
be a timely process.  We do a daily check.  Support for AVC is
already in review and has been for a couple of days now.

Now if Microsoft is not as timely with adding support for new
types GO COMPLAIN TO MICROSOFT.

If your DNS hoster hasn't updated their web panel then go complain
to your DNS hoster or find one who does support new types in a
timely manner.

ISC ships a tool that should make it easy to upgrade web panel.  It
is designed to parse all known types and emit them as UNKNOWN types
or in the canonical form of the known type.  It also supplies a
list of all known types.  The tool is named-rrchecker.

The output will work with any nameserver that supports UNKNOWN type.

We can't make DNS hosters use the tool but we can create it and
make it available for free.  Upgrading to support a new type is the
just a matter of installing a new version of the tool.

Mark

> _mmm._ndr.example.com TXT "t=tls,tcp p=http e=json
> r=MDFAE-7FBGM-LG5GK-JFIR6-QN4HO-7O3ZV"
> 
> 
> QED.
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]