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

[Petr Spacek <[e-mail]>]

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