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

From: Petr Spacek <[email-masked]>
Date: Wed, 1 Jun 2016 12:46:18 +0200

On 20.5.2016 17:06, Nico Williams wrote:
> 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.

For the record, opinions of DNS gurus from dnsop list can be found in dnsop
archives:
http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
indicates that it might be possible to standardize TXT if you try it.

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
argues that URI is good enough and that TXT is a bad practice.

Pick an answer which suits you the best :-)

> 
>>>>  - 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?  :)

Personally I think that this can be solved by some clever usage of an existing
bidirectional language + some metadata.

My experience with Augeas shows that it works quite well and that people
ironed out a lot of details and difficult corner cases so might be worth
investigating this direction.

If you do not like bidirectional languages look at
https://datatracker.ietf.org/doc/draft-levine-dnsextlang/
and implement it :-)

Have a nice day!

Petr Spacek  @  Red Hat

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

-- 
Petr Spacek  @  Red Hat

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Jun 2016 12:21:01 -0500

> bidirectional language + some metadata.

I'm not sure what you mean.  "Bi-directional language", to me, refers to
natural languages where writing is done in two directions.

> investigating this direction.

The configuration editing tool??

> https://datatracker.ietf.org/doc/draft-levine-dnsextlang/

My preference would be to use XML (I know, I know[*]), mostly because
people could (and almost certainly would) then write XSLs to generate
client- and maybe server-side code for dealing with unknown RR types.

Mostly you just need to generate a tiny bit of HTML and JavaScript to
present a UI specific to any given RR type, type-check user inputs,
provide help bubbles and such, format the RDATA with valid
user inputs, and produce hex-encoded RDATA that the server can then use
(the server doesn't need to validate the RDATA, but it could do that
too, also with generated code).

[*] XSLT is what makes XML tolerable and even desirable for this task.

I suppose one would have to... design an XML schema for this, write an
I-D and sample XSLs, submit, and see if dnsop has interest.  I don't
have the cycles for this :(

Nico
--

---

From: Petr Spacek <[email-masked]>
Date: Mon, 6 Jun 2016 15:38:30 +0200

> Pick an answer which suits you the best :-)

BTW the discussion continues on krbdev mailing list and wiki, for some reason
people there gave up on kitten...

http://mailman.mit.edu/pipermail/krbdev/2016-June/012605.html

-- 
Petr Spacek  @  Red Hat

---

From: Petr Spacek <[email-masked]>
Date: Mon, 6 Jun 2016 15:45:08 +0200

> natural languages where writing is done in two directions.

I'm sorry for being terse but the long answer is here:
https://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf

"Need to find a way of deriving both functions from a single
description" (of RR type in our case).

Of course the description could be encoded in any format. The main point is
that this conversion should be based on very solid theory to eliminate risk of
encode()/decode() inconsistencies.

> The configuration editing tool??
Yes, Augeas is using an bidirectional language.

> have the cycles for this :(

I share the same problem :-(

-- 
Petr Spacek  @  Red Hat