Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

[Nico Williams <[e-mail]>]

On Fri, May 20, 2016 at 09:26:42AM +0200, Petr Spacek wrote:
> On 19.5.2016 18:47, Nathaniel McCallum wrote:
> > On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote:
> >>  - Perhaps we should have our own RR type.  In principle it's easy to
> >>    add them, but:
> 
> Any new RR type will be in worse position than URI because of reasons you
> stated below.

Exactly.

> >>  - If new RR types are the answer, then the DNS community needs to do
> >>    something about UIs.  For example, there could be an XML schema
> >>    defining RR types' RDATA contents and UI elements.  Then
> >>    implementors could automatically translate those to code to
> >>    implement UIs for new RR types.
> 
> Oh yes, this is my plan for some time already but it always gets lower
> priority than something else ... I would not wait for it :-)

Er, OK, how do we help you implement it?  :)

> More importantly, there was literally no usage & demand for the URI
> record up to now. Adding new RR types to UI is trivial as soon as you
> have justification for the management, so the demand could simply
> solve the UI problem for the URI RR type.

Well, I hope so!  The UI for URI is going to be very similar to the UI
for SRV.

A machine-readable description of what the UI should be for each RR type
would have made this problem a non-problem, and might yet.

> >>  - Can you ask some DNS hosters to inveigh as to whether they would
> >>    be willing to add arbitrary new RR types?  (Presumably with a UI
> >>    that requires the user to paste base64-/hex-encoded RDATA.)
> 
> We have a standard for Handling of Unknown DNS RR Types:
> https://tools.ietf.org/html/rfc3597
> 
> It says that RDATA for unknown types should be typed in using hexadecimal
> notation:
> https://tools.ietf.org/html/rfc3597#section-5

Thanks.

> Also, some servers/services simply lack UI (e.g. Windows Server 2003)
> but allow adding the record using standard DNS UPDATE protocol RFC
> 2136, which is also behavior mandated by RFC 3597.

That's nice, but the services that Nathaniel is concerned about probably
don't support DNS UPDATEs.

That's another thing.  Implementations that support DNS UPDATE often
don't have useful authorization models, leading enterprises often to
having to write proxies [that invariably do not themselves speak DNS
UPDATE].  I'm not sure that a standard can help there, but I think it
might.  One idea would be to associate authorization attributes to each
RR type and RRset name pattern so that the DNS server could evaluate the
DNS UPDATE client's authorization to perform a given operation.  E.g.,
the owner(s) of a given domainname (should ownership and/or ACLs be
expressible within DNS?) might get to manage associated SRV RRsets, and
maybe (subject to site-local policy) add/delete CNAMEs pointing to that
name, but maybe not modify the A/AAAA RRsets -- the "associated" bit
would be nice if it were expressed in a standard, while which operations
are allowed should be locally expressible based on simple labels for
each association, say.

Nico
--