Opened 12 years ago

Closed 11 years ago

#32 closed defect (fixed)

Section 4

Reported by: paf@… Owned by: jon.peterson@…
Priority: minor Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: Active WG Document Keywords:
Cc:

Description

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

Change History (1)

comment:1 Changed 11 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

I think it's still worth keeping NAPTR in there as an option, so changing to "NAPTR or URI resource records." Also took out the bit about service fields/schemes here, as it really made the end of the sentence harder to understand. How about:

For example, since NAPTR or URI resource records can contain URIs, those URIs can in turn point to an external query-response service such as HTTP where more syntactically and semantically rich queries and answers might be exchanged.

Note: See TracTickets for help on using tickets.