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

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Mar 2016 07:22:36 -0800

On 2/29/2016 2:32 PM, Ray Bellis wrote:
> On 29/02/2016 22:27, John R Levine wrote:
>
>> The existing port and service registry already has all of the _service
>> names, and is updated as people invent new services.  What's the benefit
>> of duplicating it rather than just pointing to it?
>
> +1

So this commentr sequence is tending to convince me to have the document 
stay away from saying anything about SRV's subordinate _underscore name 
field, _Service.

However for _Proto, there remains a basic problem with the current SRV 
arrangement, in the face of an _underscore registry:  name collision.

If SRV continues to specify _Proto choices from a separate IANA 
registry, there there are two, /independent/ places for doing 
_underscore registrations.  That model ensures name collisions.

While I doubt that all 7000 service names, or even a small fraction of 
them, get used for SRV, whatever percentage does get used is likely to 
be a large-ish number.  So, yeah, having to duplicate the registration 
is problematic.

In the case of _Proto names, the set is tiny, so the burden of 
explicitly registering these names in an _underscore registry is not 
onerous, given that it is the only way to ensure that name collisions 
are avoided.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 1 Mar 2016 16:39:05 -0000

>registry, ....

It never did and does not now.  There is no protocol name registry or
_proto tag registry.  (There is a S-NAPTR application protocol tag
registry, but since it contains entries like "diameter.tls.tcp" this
is not the registry you are looking for.)

>onerous, given that it is the only way to ensure that name collisions 

I agree.  The current set of _proto names used by SRV. NAPTR, and URI
is sort of defined by examples and hints.  RFC 2782 which defined SRV
calls out _TCP and _UDP as interesting protocols and then waves its
hands about possible other ones.  It creates no registry.  

RFC 6335 calls out SCTP, DCCP, TCP, and UDP as interesting protocols,
and then says that future protocols that support services should use
the same services registry.  It has a lot of advice for IANA, but it
doesn't create a protocol name or tag registry either.

RFC 2780 created a protocol number registry updated by RFCs 5237 and
7045.  It has a "keyword" column, but many of the keywords include
undesirable characters like +./.  Most of the protocols are dead
experiments from 20 or 30 years ago, and most of the live ones like
ICMP aren't suitable for services.  One possibility would be to add a
tag column to that registry and populate it with the four tags that
seem plausibly useful.  But ugh.

The other which I prefer is simply to put the four _proto tags into
the new underscore registry.  Add a note that they have subnames from
the RFC 6335 services registry, and for anew new protocol tags try to to
keep the protocol names consistent with the keywords in the protocol
number registry.

I see the universe of underscore tags falling into three categories.

1.  Tags that mean something under a hostname.  This includes the
_proto tags and things like _domainkey and _vouch.

2.  Tags that only mean something under a _proto tag.  This is 
the set of service names in the RFC 6335 registry and _nnn (port number)
used to name TLSA records.

3.  Tags that only mean something under some other underscore tag.
This is a very small list, _adsp._domainkey and _report._dmarc are
the only ones I know.

It would be useful to define the registry for the first kind of tags.
The second already has a registry, the third is uninteresting since it
has no collision issues.

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Tue, 1 Mar 2016 16:46:31 +0000

> keep the protocol names consistent with the keywords in the protocol

This, exactly.

I'd suggest that perhaps the keywords from the protocol registry (or a
canonical representation thereof, for those that don't match LDH) should
actually be reserved ?

> The second already has a registry, the third is uninteresting since it

All that, too.

Ray

---

From: "John Levine" <[email-masked]>
Date: 1 Mar 2016 16:56:33 -0000

>canonical representation thereof, for those that don't match LDH) should

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.

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Tue, 1 Mar 2016 16:59:14 +0000

> 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" ?

Ray

---

From: Dave Crocker <[email-masked]>
Date: Tue, 1 Mar 2016 09:00:22 -0800

> canonical representation thereof, for those that don't match LDH) should

yeah, that makes sense.

d/

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2016 12:01:09 -0500

> protocol registry that _should_ be reserved in the underscore registry,

Not that I can see, but take a look and maybe I missed something.  It has 
under 150 entries:

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Mar 2016 12:55:34 -0500

> protocol registry that _should_ be reserved in the underscore registry,

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.

---

From: "John Levine" <[email-masked]>
Date: 1 Mar 2016 18:13:32 -0000

>that only uses the service prefix.

Maybe.

>implicit use of TLS?

The practice to date has been to register separate service names for
versions of a service that do implicit TLS, e.g., http and https, imap
and imaps, pop3 and pop3s, sip and sips.  This is a kludge but it's a
well established kludge.  Service names are cheap, so it's a cheap
kludge.

> If so what factors would determine the SSL trust anchor?

RFC 6698 would tell you to look up the TLSA record at
_443._tcp.example.com.  (Note the port number rather than service
name, specifically to handle TLS services on nonstandard ports.)  In
the absence of DANE you presumably use whatever trust anchor you use.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Mar 2016 13:20:26 -0500

> well established kludge.  Service names are cheap, so it's a cheap

Actually there is also a practice of using TXT records as well. I was
surprised when I found out about it. The folk who have written this
all up have not done a good job of advertising it.

> the absence of DANE you presumably use whatever trust anchor you use.

That works for TLS but not if you have multiple
packet/transport/presentation layer options.

For most of my protocols, I want to apply security enhancements at
multiple layers. DANE is more hindrance than help.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Mar 2016 09:51:38 +1100

> 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

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2016 18:15:22 -0500

> sure there are similar announcements for other nameserver vendors.

I suppose I could say web based configuration crudware a few dozen more 
times, but I doubt it would sink in any more than it has before.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Mar 2016 10:37:35 +1100

> Please consider the environment before reading this e-mail.

Look at https://ednscomp.isc.org/compliance/summary.html.

The EDNS COOKIE code point was only allocated in July.  You have
TLD operators and Alex top 1000 operators supporting it and we don't
yet have the RFC out the door.  Named's support in BIND 9.10.3
requires the nameserver builder to turn it on at configure time
unless you are running it on Windows where it is on by default.

[ I've heard one of the Linux vendors turns it on at compile time. ]

It will be on by default in BIND 9.11.0.

Slowness in supporting new types is not the problem of nameserver
vendors.  Support for routine extensions to the DNS actually gets
done in a timely manner.  Universal support takes a long time (which
you can also see in those graphs) but you don't need universal
support for new types.  You need a resolver that can perform the
lookup if you want to use the new type and the ability to publish
the record.

Mark

---

From: Jared Mauch <[email-masked]>
Date: Tue, 1 Mar 2016 18:46:21 -0500

> times, but I doubt it would sink in any more than it has before.

	I've seen organizations that don't upgrade/patch software if
they feel it can be mitigated with other technical means because
alterting them would require hypothetical testing that they won't do.

	With the recent stream of security updates in the past 2-3 years
to bash, OpenSSL, etc.. they have started to change their stance.  I
understand the goals of 'change one thing at a time' so it's easy to 
know what introduced the breakage, but at some point people who fail
to upgrade will cease to work.

	I was helping with a router today where the lack of a proper clock
meant it could not generate a SSH key because the crypto system
would not work.  We are creating a more fragile ecosystem at times
for the sake of security, and things will break along the way.

	I have my opinions about techical malpractice in this space and
have been guilty myself of it at times, but we can't let outdated
people hold back forward progress.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: "John R Levine" <[email-masked]>
Date: 1 Mar 2016 19:01:34 -0500

> Look at https://ednscomp.isc.org/compliance/summary.html.

I did.  It has nothing to do with configuration software or new RRTYPEs, 
which demonstrates my point.

R's,
John

PS: For a good time see https://datatracker.ietf.org/doc/draft-levine-dnsextlang/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Mar 2016 19:24:16 -0500

In response to the discussion of where the use of TXT records is discussed, see:

https://tools.ietf.org/html/rfc6764

This in turn cites:

https://tools.ietf.org/html/rfc6763#section-6

Which seems like the way to do these things.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Mar 2016 14:43:49 +1100

In message <[email-masked]>, "John R Levine" write
> which demonstrates my point.

You missed the point that new code points are making their way into
production servers in a timely manner but if you want to see types
all the servers that supported expire also support:

a a6 aaaa afsdb apl caa cdnskey cds cert cname dhcid dlv dname
dnskey ds eui48 eui64 gpos hinfo hip ipseckey isdn key keydata kx
l32 l64 loc lp mb md mf mg minfo mr mx naptr nid ns nsap nsap-ptr
nsec nsec3 nsec3param null nxt opt ptr px rp rrsig rt sig soa spf
srv sshfp tkey tlsa tsig txt unspec uri wks x25

avc and openpgpkey are the only ones missing from that list and
openpgpkey has since been published (those that support cookie
support openpgpkey) and avc only got a code point allocated last
week.

It doesn't take years, in general, for new types to make it into
production servers.

Mark