Re: Review of: draft-iab-dns-applications-01

[Patrik Fältström <[e-mail]>]

FWIW, in general I think the document is good, and I am not a person that get hang up much things... Other people are much better on giving such comments ;-)

But, I think there is one section that should have an addition, of possible change, end of section 4:

>    In cases where applications require these sorts of features, they are
>    simply better instantiated by independent application-layer protocols
>    than the DNS.  The query-response semantics of the DNS are easily
>    replicated by HTTP, for example, and the objects which HTTP can carry
>    both in queries and responses can easily contain the necessary
>    structure to manage compound queries.  Similarly, HTTP has numerous
>    ways to provide the necessary authentication, authorization and
>    confidentiality properties that some features require.
> 
>    Where the administrative delegations of the DNS form a necessary
>    component in the instantiation of an application feature, there are
>    various ways that the DNS can bootstrap access to an independent
>    application-layer protocol better suited to field the queries in
>    question.  For example, since NAPTR records can contain URIs, those
>    URI can point to an external query-response service such as HTTP,
>    with a NAPTR service field that signal to applications that questions
>    of interest can be answered at that service.

FWIW, I went through (together with Olaf) a registration process of the URI Resource Record Type that would help solving exactly this problem. To be a tool in between SRV and NAPTR, where a prefix on an owner do sub selection of records (like SRV, instead of inside RDATA like NAPTR), and the RDATA is ordered set of URIs (instead of more complicated NAPTR RDATA structure that require rewrite rules in the DDDS), and be more structured that storing URIs in TXT records.

URI is registered as RR TYPE 256 since a while back (not too long though).

So, let me suggest the last sentence is changed to the following (because I think referencing a NAPTR and because of the requirement of defining a DDDS, when in reality the only thing one want is OWNER -> URI mapping):

> For example, since URI records can contain URIs, those
> URIs can point to an external query-response service such as HTTP,
> where the prefix of the URI is used by the applications to select
> the RR SET, and because of the HTTP based services, that is of interest.

   Patrik