Re: new DNS classes

[Nico Williams <[e-mail]>]

On Fri, Jul 07, 2017 at 04:56:37PM +1000, Mark Andrews wrote:
> In message <20170707055315.GC3393@localhost>, Nico Williams writes:
> > We've struggled with this in KITTEN WG.  Deploying the URI RR type when
> > you're using a hosting service can be anywhere from annoying (must enter
> > raw RDATA) to impossible (the hosting service doesn't give a damn).  I
> > suppose it's just a matter of time; perhaps things have improved since
> > we last looked.
> 
> Then change domain hosting providers and tell them why or run you
> own master server or use a service which allows for dynamic updates
> which shouldn't care about the record types.  There are plenty of
> DNS providers that will slave content.

That's easy enough if *I* am the user.  Of course I can change hosting
providers.  However, it's NOT easy when your *customer* is the user that
has to change hosting providers -- they'll balk, and you'll just work
around it.

In the KITTEN WG case there definitely was a vendor who needed to
support customers who use hosting providers that didn't support the URI
RR type.  Can you blame them for not wanting to go with the URI RR type?

Sure we should do it anyways -- it might help.  But that vnedor will
still have to cope with cases where URI is not available, and that
actually means falling back onto alternative, possibly slower, methods
that need to be specified too and which might have annoying knock-on
effects.

(In the KITTEN WG case the idea is to improve discovery of Kerberos KDC
services.  We currently use SRV RRs, but this requires multiple
requests, and every time we add a new transport we need to add more
requests.  One could parallelize the requests, but that's not
necessarily very nice, and anyways, it sucks from a resolver API
perspective.  A URI RR type would solve the problem.  But if you have to
fallback then you've slowed things down for what might be the common
case.)

> As a DNS server vendor we get requests to add the new type within
> days the type being allocated.  We usually already have code written
> and merged to support the new type in all current branches before
> those request come in as we poll the type registry daily.  It is
> available over git to anyone that wants to pull it down support for
> the new type prior to the next maintainence releases.  Adding a new
> type is as simple as adding to files to the source tree and rebuilding
> the tools.  Once that is done all the tools we ship support it.

Of course.  *You* are NOT the problem.  That's great.  The problem is
always some knucklehead somewhere who doesn't care to fix *their* system.

Nico
--