Skip to main content

The Uniform Resource Identifier (URI) DNS Resource Record
draft-faltstrom-uri-14

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'The Uniform Resource Identifier (URI) DNS Resource Record' to Informational RFC (draft-faltstrom-uri-14.txt)

The IESG has approved the following document:
- 'The Uniform Resource Identifier (URI) DNS Resource Record'
  (draft-faltstrom-uri-14.txt) as Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-faltstrom-uri/


Ballot Text

Technical Summary

   This document describes the already registered DNS resource record
   type called the Uniform Resource Identifier (URI) RR, for publishing
   mappings from hostnames to URIs.

Working Group Summary

   The document was discussed briefly in the Apps Area WG and the DNSOP
   WG, and the now-closed DNSEXT WG, with no significant objections. The
   registration for the new resource record type was already approved by
   the expert reviewer a few years ago. Last Call discussion turned out
   to be lively, and the conclusion was that this should simply be an
   Informational document and not Standards Track.

Document Quality

   The draft is pretty simple, and has been rolling around for many
   years with only minor modifications. It is already implemented in
   some widely-used DNS software. There has already been an INT-DIR
   review of this document. Last Call discussions centered around the
   document's focus on using this for the web, which was deemed
   problematic, both regarding security considerations and the fact that
   there is unlikely to be deployment in that area, and on its attempt
   to introduce a new NAPTR flag. Security Considerations were updated
   accordingly, the example was changed, and the discussion of the new
   NAPTR flag was removed. There is consensus around this being a good
   informational description of the RR.

Personnel

   Paul Hoffman is the document shepherd.
   Pete Resnick is the responsible Area Director.

RFC Editor Note

Please make the following changes:

Section 1:

OLD
   Historically, uses of the DNS to map a domain name to a URL have
   relied on the NAPTR RRTYPEs and then on the DDDS [RFC3401]
   application framework with the DNS as a database as specified in RFC
   3404 [RFC3404].
NEW
   Historically, uses of the DNS to map a domain name to a URL have
   relied on the Naming Authority Pointer (NAPTR) RRTYPEs [RFC2915] and
   then on the Dynamic Delegation Discovery System (DDDS) [RFC3401]
   application framework with the DNS as a database as specified in RFC
   3404 [RFC3404].

Section 2:

OLD
   Applications MUST know the specific service to prepend the hostname
   with.  Using repetitive queries for URI records MUST NOT be a
   replacement for querying for NAPTR records according to the NAPTR
   (DDDS) or S-NAPTR algorithms.
NEW
   Applications need to know the specific service to prepend the
   hostname with.  Using repetitive queries for URI records is not a
   replacement for querying for NAPTR records according to the NAPTR
   (DDDS) or S-NAPTR algorithms.

Section 7:
OLD
   will effectlyely lead to a downgrade attack.
NEW
   will effectively lead to a downgrade attack.

RFC Editor Note