Last Call: <draft-ietf-dnsext-dnssec-bis-updates-18.txt> (Clarifications and Implementation Notes for DNSSECbis) to Proposed Standard

The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Clarifications and Implementation Notes for DNSSECbis'
  <draft-ietf-dnsext-dnssec-bis-updates-18.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2012-05-31. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document is a collection of technical clarifications to the
   DNSSECbis document set.  It is meant to serve as a resource to
   implementors as well as a repository of DNSSECbis errata.

   This document updates the core DNSSECbis documents (RFC4033, RFC4034,
   and RFC4035) as well as the NSEC3 specification (RFC5155).  It also
   defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/ballot/

No IPR declarations have been submitted directly on this I-D.

[Technical Errata Reported] RFC3363 (3220)

The following errata report has been submitted for RFC3363,
"Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3363&eid=3220

--------------------------------------
Type: Technical
Reported by: Mark Andrews <marka <at> isc.org>

Section: 4

Original Text
-------------
4.  DNAME in IPv6 Reverse Tree

   The issues for DNAME in the reverse mapping tree appears to be
   closely tied to the need to use fragmented A6 in the main tree: if
   one is necessary, so is the other, and if one isn't necessary, the
   other isn't either.  Therefore, in moving RFC 2874 to experimental,
   the intent of this document is that use of DNAME RRs in the reverse
   tree be deprecated.

Corrected Text
--------------
4. DNAME in IPv6 Reverse Tree

[Deleted due to faulty premise.]

[reed <at> reedmedia.net: comments on draft-weiler-dnsext-dnssec-bis-updates 18]

Forwarded as suggested.  I think the draft name is misspelled.

A

----- Forwarded message from "Jeremy C. Reed" <reed <at> reedmedia.net> -----

Date: Mon, 7 May 2012 11:21:20 -0500 (CDT)
From: "Jeremy C. Reed" <reed <at> reedmedia.net>
To: ajs <at> anvilwalrusden.com
Subject: comments on draft-weiler-dnsext-dnssec-bis-updates 18

The following are my comments on 
draft-weiler-dnsext-dnssec-bis-updates-18.  You may forward my comments 
or reply on list as desired.

4.3.  Check for CNAME

   Section 5 of [RFC4035] says little about validating responses based
   on (or that should be based on) CNAMEs. 

* The wording above is confusing or misleading. RFC 4035 Section 5 says 
nothing about CNAME specifically.

5.3.  Private Algorithms

...

   In the remaining cases, the security status of the zone depends on
   whether or not the resolver supports any of the private algorithms in
   use (provided that these DS records use supported hash functions, as

I-D Action: draft-ietf-dnsext-rfc6195bis-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the DNS Extensions Working Group of the IETF.

	Title           : Domain Name System (DNS) IANA Considerations
	Author(s)       : Donald E. Eastlake
	Filename        : draft-ietf-dnsext-rfc6195bis-01.txt
	Pages           : 19
	Date            : 2012-05-02

   This document specifies Internet Assigned Number Authority (IANA)
   parameter assignment considerations for the allocation of Domain Name
   System (DNS) resource record types, CLASSes, operation codes, error
   codes, DNS protocol message header bits, and AFSDB resource record
   subtypes.  It obsoletes RFC 6195.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc6195bis-01.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc6195bis/

_______________________________________________
dnsext mailing list

Publication request: draft-ietf-dnsext-dnssec-bis-updates

Dear Ralph, 

This is a request for publication of
draft-ietf-dnsext-dnssec-bis-updates-18 as a Proposed Standard.  The
standard write-up is attached.  Upon sending this message, I will
update the document status in the datatracker.

Best regards,

A
-- 
Andrew Sullivan
ajs <at> crankycanuck.ca

PROTO write up for draft-ietf-dnsext-dnssec-bis-updates-18
2012-05-01
Template version 2012-02-24

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

    The request is for Proposed Standard.  The documents it is
    updating are all at the Proposed Standard level, and this document
    reflects experience with and clarifications of those.  The type is
    indicated in the header.

(2) The IESG approval announcement includes a Document Announcement

I-D Action: draft-ietf-dnsext-dnssec-bis-updates-18.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the DNS Extensions Working Group of the IETF.

	Title           : Clarifications and Implementation Notes for DNSSECbis
	Author(s)       : Samuel Weiler
                          David Blacka
	Filename        : draft-ietf-dnsext-dnssec-bis-updates-18.txt
	Pages           : 20
	Date            : 2012-04-30

   This document is a collection of technical clarifications to the
   DNSSECbis document set.  It is meant to serve as a resource to
   implementors as well as a repository of DNSSECbis errata.

   This document updates the core DNSSECbis documents (RFC4033, RFC4034,
   and RFC4035) as well as the NSEC3 specification (RFC5155).  It also
   defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-18.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-bis-updates-18.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/

Re: (fwd) New Version Notification for draft-ietf-dnsext-rfc1995bis-ixfr-01

Internet-Drafts <internet-drafts <at> ietf.org> just wrote:

> A new version of I-D, draft-ietf-dnsext-rfc1995bis-ixfr-01.txt
> has been successfully submitted by Alfred Hoenes and posted
> to the IETF repository.
>
> Filename:        draft-ietf-dnsext-rfc1995bis-ixfr
> Revision:        01
> Title:           DNS Incremental Zone Transfer Protocol (IXFR)
> Creation date:   2012-04-23
> WG ID:           dnsext
> Number of pages: 34
>
> Abstract:
>    The standard means within the Domain Name System protocol for
>    maintaining coherence among a zone&#39;s authoritative name servers
>    consists of three mechanisms.  Incremental Zone Transfer (IXFR) is
>    one of the mechanisms and originally was defined in RFC 1995.
>
>    This document aims to provide a more detailed and up-to-date
>    specification of the IXFR mechanism and to align it with the current
>    specification of the primary zone transfer mechanism, AXFR, given in
>    RFC 5936.  Further, based on operational experience, this document
>    juxtaposes to the original IXFR query a new query type, IXFR-ONLY,
>    that will likely be preferred over IXFR in specific deployments.
>
>    This document obsoletes and replaces RFC 1995.
>
>
> The IETF Secretariat

rfc6195bis registration template clarification

I tried to figure out whether the rfc1995bis-ixfr draft needs
to undergo the RRtype Expert Review per RFC 6195[bis].

It looks like that review only pertains to Data and Meta-RRtypes,
(and the draft -- targeting Standards Track -- needs IETF review),
but the registration policy table for RRtypes (entry for range
128-255) could be misunderstood to indicate otherwise.

When looking at the registration template in RFC 6195[bis],
I missed a structured opportunity for the applicant to indicate
whether the application is for a Data RR or Meta-RR, which would
be significant for IANA to select a proper numerical range in the
assignment process.

So I suggest to amend clause B. of the template in Appendix A of
the rfc6195bis I-D as follows:

OLD:

|  B. Submission Type:
|     [ ] New RRTYPE
|     [ ] Modification to existing RRTYPE

NEW:

|  B. Submission Type:
|     [ ] New RRTYPE
|     [ ] Modification to existing RRTYPE
|
|     Kind of RRTYPE:

I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the DNS Extensions Working Group of the IETF.

	Title           : Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
	Author(s)       : Scott Rose
	Filename        : draft-ietf-dnsext-dnssec-algo-imp-status-02.txt
	Pages           : 6
	Date            : 2012-04-19

   The DNS Security Extensions (DNSSEC) requires the use of
   cryptographic algorithm suites for generating digital signatures over
   DNS data.  There is currently an IANA registry for these algorithms
   that is incomplete in that it lacks the recommended implementation
   status of each algorithm.  This document provides an applicability
   statement on algorithm implementation status for DNSSEC component
   software.  This document lists each algorithm's status based on the
   current reference.  In the case that an algorithm is specified
   without an implementation status, this document assigns one.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-algo-imp-status-02.txt

_______________________________________________

I-D Action: draft-ietf-dnsext-rfc2672bis-dname-26.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the DNS Extensions Working Group of the IETF.

	Title           : DNAME Redirection in the DNS
	Author(s)       : Scott Rose
                          Wouter Wijngaards
	Filename        : draft-ietf-dnsext-rfc2672bis-dname-26.txt
	Pages           : 22
	Date            : 2012-04-19

   The DNAME record provides redirection for a sub-tree of the domain
   name tree in the DNS system.  That is, all names that end with a
   particular suffix are redirected to another part of the DNS.  This is
   a revision to the original specification in RFC 2672 (which this
   document obsoletes) as well as updating RFC 3363 and RFC 4294 to
   align with this revision.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-26.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-26.txt

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org

draft-ietf-dnsext-rfc1995bis-ixfr -- questions on s3.2.3

Note:
  This thread actually has started on the predecessor individual
  draft, but to acoid confusion on the target of the discussion,
  I have changed the Subject to refer to the adopted WG draft,
  draft-ietf-dnsext-rfc1995bis-ixfr-00.

The questions were about the level and detail of the requirements
posed onto an IXFR server in packetizing the conceptual IXFR
response -- in all the different cases that can occur --, and how
thereby the detrimental need for IXFR clients to rely on timeouts
(to determine the outcome/state of an IXFR session, under very
specific conditions) can be avoided.

I have revisited recent messages and previous work, and tried
to arrive at the conclusions that look most reasonable and seem
to correspond to evolving consensus.

Observations and conclusions:

(1)
IXFR is intended as a more efficient method for in-band zone
synchronization than AXFR (for deployment scenarios where it
makes sense -- as explained in the draft); therefore, it seems
fair that the specification is tailored to support timely,
efficient completion of IXFR sessions under most conditions,
and that the requirements for IXFR server implementations be
at least as strong as the comparable requirements for modern
AXFR servers that fully conform to RFC 5936 (excluding the
kludges for backward compatibility still supported by that RFC).