"IETF Secretariat" | 24 Jun 18:00 2016

dnsop - Requested session has been scheduled for IETF 96

Dear Tim Wicinski,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

dnsop Session 1 (2:00:00)
    Monday, Afternoon Session II 1540-1740
    Room Name: Bellevue size: 200

Request Information:

Working Group Name: Domain Name System Operations
Area Name: Operations and Management Area
Session Requester: Tim Wicinski

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 140
Conflicts to Avoid: 
 First Priority: dbound dane dhc apparea appsawg homenet dnssd dprive
 Second Priority: mif intarea trans v6ops
 Third Priority: sidr saag pcp opsawg opsarea grow 6man

Special Requests:


(Continue reading)

Davey Song | 22 Jun 08:44 2016

Fwd: New Version Notification for draft-song-dns-wireformat-http-04.txt

Hi Colleagues,

Regarding the DNS wire-format over HTTP draft, the authors replied and addressed all comments in the mailing list. The latest update (04) reflect the comments on simplify the description of HTTP syntax and make the protocol less tied related to HTTP version

Can I ask for a call for this document (adoption as WG draft )? Any suggestion is appreciated.

Best regards,
---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: 22 June 2016 at 14:31
Subject: New Version Notification for draft-song-dns-wireformat-http-04.txt
To: "Paul A. Vixie" <vixie <at> tisf.net>, Shane Kerr <shane <at> biigroup.cn>, Runxia Wan <rxwan <at> biigroup.cn>, Linjian Song <songlinjian <at> gmail.com>

A new version of I-D, draft-song-dns-wireformat-http-04.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:           draft-song-dns-wireformat-http
Revision:       04
Title:          DNS wire-format over HTTP
Document date:  2016-06-21
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-song-dns-wireformat-http-04.txt
Status:         https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/
Htmlized:       https://tools.ietf.org/html/draft-song-dns-wireformat-http-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-song-dns-wireformat-http-04

   This memo introduces a way to tunnel DNS data over HTTP.  This may be
   useful in any situation where DNS is not working properly, such as
   when there is middlebox misbehavior.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

DNSOP mailing list
DNSOP <at> ietf.org
rfc-editor | 22 Jun 01:58 2016

RFC 7901 on CHAIN Query Requests in DNS

A new Request for Comments is now available in online RFC libraries.

        RFC 7901

        Title:      CHAIN Query Requests in DNS 
        Author:     P. Wouters
        Status:     Experimental
        Stream:     IETF
        Date:       June 2016
        Mailbox:    pwouters <at> redhat.com
        Pages:      16
        Characters: 35252
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-dnsop-edns-chain-query-07.txt

        URL:        https://www.rfc-editor.org/info/rfc7901

        DOI:        http://dx.doi.org/10.17487/RFC7901

This document defines an EDNS0 extension that can be used by a
security-aware validating resolver configured to use a forwarding
resolver to send a single query, requesting a complete validation
path along with the regular query answer.  The reduction in queries
potentially lowers the latency and reduces the need to send multiple
queries at once.  This extension mandates the use of source-IP-
verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot
be abused in amplification attacks.

This document is a product of the Domain Name System Operations Working Group of the IETF.

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

DNSOP mailing list
DNSOP <at> ietf.org

Tim Wicinski | 21 Jun 22:15 2016

DNSOP Working Group Session in Berlin - agenda, et al


I feel we have angered the scheduling gods as they have placed DNSOP 
back on Friday morning from 10:00-12:00 am.   We've asked the 
secretariat to reconsider, but with more requests for slots than the 
schedule holds, I suspect no one will be pleased.

We've already had a few requests for agenda time, but if you wish to add 
something please drop the chairs a note.  Priority is always given to 
work in progress with active discussions.



DNSOP mailing list
DNSOP <at> ietf.org

Jiankang Yao | 17 Jun 10:36 2016

bname draft and its related bar bof

Dear all,
     this draft was discussed in dnsext a few years ago. It has been updated to a new version.
    It redesigns the method of how to compatible with DNSSEC.
   If the resolver sends no signaling of bname support but with DNSSEC, the server does the following thing:
1). the server issues cname and its signature when querying the same owner name with BNAME
2). the server issues dname and its signature when querying the children of the same owner name of BNAME
PS: the server prepares the siganture of CNAME and DNAME beforehand. 
    If you have already with the key idea of this draft, you can focus on section 5 and 6.

  Could you kindly help to review it?

   any comments are welcome.

BTW,  We would like to hold a bar bof in the Berlin IETF meeting, discussing the issues related to bundled domain names' DNS resolution and its possible solution. 
if you are interested in it, pls kindly let me know it or subscribe it via https://www.ietf.org/mailman/listinfo/bundled-domain-names  
 thanks  a lot.
Jiankang Yao
Date: 2016-05-23 14:30
Subject: New Version Notification for draft-yao-dnsext-bname-06.txt
A new version of I-D, draft-yao-dnsext-bname-06.txt
has been successfully submitted by Jiankang YAO and posted to the
IETF repository.
Name: draft-yao-dnsext-bname
Revision: 06
Title: Bundled DNS Name Redirection
Document date: 2016-05-23
Group: Individual Submission
Pages: 15
URL:            https://www.ietf.org/internet-drafts/draft-yao-dnsext-bname-06.txt
Status:         https://datatracker.ietf.org/doc/draft-yao-dnsext-bname/
Htmlized:       https://tools.ietf.org/html/draft-yao-dnsext-bname-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-yao-dnsext-bname-06
   This document defines a new DNS Resource Record called "BNAME", which
   provides the capability to map itself and its subtree of the DNS name
   space to another domain.  It differs from the CNAME record which only
   maps a single node of the DNS name space, from the DNAME which only
   maps the subtree of the DNS name space to another domain.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
DNSOP mailing list
DNSOP <at> ietf.org
Ray Bellis | 16 Jun 16:59 2016

Call for Presentations - DNS-OARC Fall Workshop, Dallas, Oct. 2016

[with apologies to those who see this on multiple lists]

Call for Presentations

The DNS-OARC 25th Workshop will take place in Dallas, Texas during
October 15th and 16th 2016, the Saturday and Sunday before NANOG68. To
attract the best DNS minds, DNS-OARC is requesting proposals for
presentations, with a preference for Resolver's Operations experiences,
including running DNSSEC validating resolvers.

This workshop intends to build from previous strong DNS-OARC workshops,
where both operational content and research are welcome. All DNS-related
subjects are accepted. If you are an OARC member, and have a sensitive
topic you would like to present for members-only, we will accommodate
those talks too. A timeslot will be available for lightning talks (5-10
minutes) on Sunday October 16th, for which submissions will be accepted
during October 15th on a first-come first-served basis.

Workshop Milestones
15th June 2016, Call for Presentations posted and open for submissions
14th August 2016, Deadline for submission
1st September 2016, Final Program published
10th October 2016, Final deadline for slideset submission

Details for presentation submission will be published here:


The workshop presentations will be organized by common themes, depending
on the topics and the timing of each presentation. There are 30-minute
and 15-minute slots, let us know your preference in your submission. To
ensure the quality of the workshop, submissions should include slides.
Draft slides are acceptable on submission.

You can contact the Programme Committee:


via <submissions <at> dns-oarc.net> if you have questions or concerns.

Sebastian Castro, for the OARC Programme Committee

OARC is also seeking sponsorship for this workshop, please contact
<sponsor <at> dns-oarc.net> if your organization is interested in becoming a

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

DNSOP mailing list
DNSOP <at> ietf.org

Mukund Sivaraman | 13 Jun 16:16 2016

Request reviews of catalog zones draft (draft-muks-dnsop-dns-catalog-zones-01)

Hi everybody

On Mon, Jun 13, 2016 at 06:52:27AM -0700, internet-drafts <at> ietf.org wrote:
> A new version of I-D, draft-muks-dnsop-dns-catalog-zones-01.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
> Name:		draft-muks-dnsop-dns-catalog-zones
> Revision:	01
> Title:		DNS catalog zones
> Document date:	2016-06-13
> Group:		Individual Submission
> Pages:		18
> URL:            https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-catalog-zones-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/
> Htmlized:       https://tools.ietf.org/html/draft-muks-dnsop-dns-catalog-zones-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dns-catalog-zones-01
> Abstract:
>    This document describes a method for automatic zone catalog
>    provisioning and synchronization among DNS primary and secondary
>    nameservers by storing and transferring the catalogs as regular DNS
>    zones.

Catalog zones is a new feature in BIND scheduled to be released in 9.11.
We request reviews of revision -01 the catalog zones draft.

The concept is similar to "metazones". It lets nameserver operators
provision (add/delete) zones on secondary nameservers automatically
using a special zone called a catalog zone representing an RFC 1035
catalog, which contains a list of zones (the catalog) and their
associated configuration. Updates to the catalog zone are automatically
picked up by secondaries and newly added zones are automatically setup,
and deleted ones are automatically removed on these secondary

An alpha preview of the implementation is available in BIND
9.11.0a3 (alpha) release: http://www.isc.org/downloads/

You can use this if you want to play with the feature, or if you are a
DNS developer and want to implement support for catalog zones.

An article by Jan-Piet Mens about the BIND 9.11 implementation:

A presentation about it (in Polish):

PowerDNS has a preliminary implementation for catalog zones, by
Peter van Dijk (Habbie): https://github.com/PowerDNS/powercatz

The goal of making this an internet draft is interoperability.  We are
hoping for this to become a standard catalog provisioning method among
DNS implementations. To help this forward, catalog zones uses DNS
protocol purely without any other out-of-band protocols, is designed not
to conflict with RFC 1035 name limits, and the zone configuration
represented in a catalog zone should be usable across DNS server

As interoperability is high on our minds, we look to take the draft
through the WG.

DNSOP mailing list
DNSOP <at> ietf.org
internet-drafts | 10 Jun 17:40 2016

I-D Action: draft-ietf-dnsop-maintain-ds-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : Managing DS records from parent via CDS/CDNSKEY
        Authors         : Olafur Gudmundsson
                          Paul Wouters
	Filename        : draft-ietf-dnsop-maintain-ds-03.txt
	Pages           : 9
	Date            : 2016-06-10

   RFC7344 specifies how DNS trust can be partially maintained in-band
   between parent and child.  There are two features missing in that
   specification: initial trust setup and removal of trust anchor.  This
   document addresses both these omissions.

   Changing a domain's DNSSEC status can be a complicated matter
   involving multiple unrelated parties.  Some of these parties, such as
   the DNS operator, might not even be known by all the organizations
   involved.  The inability to disable DNSSEC via in-band signalling is
   seen as a problem or liability that prevents some DNSSEC adoption at
   large scale.  This document adds a method for in-band signalling of
   these DNSSEC status changes.

   Initial trust is considered in general to be a hard technical
   problem, this document sets forth reasonable policies that clarify
   and simplify the initial acceptance policy.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

DNSOP mailing list
DNSOP <at> ietf.org

Peter DeVries | 9 Jun 15:14 2016

Authoritative Servers and the AD bit

Is there updated text that matches this from RFC3655:

"The AD bit MUST only be set if DNSSEC records have been requested via
the DO bit [RFC3225] and relevant SIG records are returned."

We are observing a system that is setting the AD bit both without the
DO bit set in the query and without supplying RRSIGs but I can't find
any relevant text in the new RFCs.

Thank you,

DNSOP mailing list
DNSOP <at> ietf.org

The IESG | 3 Jun 19:12 2016

Last Call: <draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt> (DNSSEC Roadblock Avoidance) to Best Current Practice

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNSSEC Roadblock Avoidance'
  <draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt> as Best Current

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 2016-06-17. 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.


   This document describes problems that a DNSSEC aware resolver/
   application might run into within a non-compliant infrastructure.  It
   outline potential detection and mitigation techniques.  The scope of
   the document is to create a shared approach to detect and overcome
   network issues that a DNSSEC software/system may face.

The file can be obtained via

IESG discussion can be tracked via

The following IPR Declarations may be related to this I-D:


DNSOP mailing list
DNSOP <at> ietf.org

Petr Spacek | 31 May 09:08 2016

New usage for TXT RR type on radar: Kerberos service discovery


I would like to draw attention of dnsop WG to discussion about new service
discovery method for Kerberos:

Please see
and its continuation

Main arguments for using TXT instead of URI RR type are:
> We had been planning to use the URI record type, but after a recent
> round of discussion, we don't think it's likely that popular DNS hosting
> providers will allow customers to create URI records (since it seems
> like no one else is using them).  Some middle-boxes would also block DNS
> queries for URI records.  That problem would be even worse if we create
> a new record type.  So, we are planning to use the TXT record type.  It
> seems unlikely that we can standardize on a TXT record through the IETF
> (except perhaps as an informational RFC), but it seems like the only
> deployable option for individuals and small organizations

Could someone validate these assumptions?

I do not like TXT but I'm not in position to judge validity of these arguments.

Thank you for your time.


Petr Spacek   <at>   Red Hat

DNSOP mailing list
DNSOP <at> ietf.org