Paul Hoffman | 25 Sep 01:59 2014

Bi-weekly reminder of the documents for the WG

Greetings again. This is a reminder that the documents that this WG is working on, and may or may not be
working on in the future, is at
It helps the WG chairs to know which documents have enough people willing to review them to move them
forwards. If you would like to volunteer to be a reviewer for any of the documents, please let me know so I can
list you.

If you want to add a document to the list, contact the WG chairs.

--Paul Hoffman, secretary
DNSOP mailing list
DNSOP <at>

The IESG | 24 Sep 15:08 2014

Last Call: <draft-ietf-dnsop-as112-dname-04.txt> (AS112 Redirection using DNAME) to Informational RFC - (dname and additional zones)

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'AS112 Redirection using DNAME'
  <draft-ietf-dnsop-as112-dname-04.txt> as Informational RFC

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> mailing lists by 2014-10-08. Exceptionally, comments may be
sent to iesg <at> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Subsequent to the IETF Last call on this document. questions arose as 
to wether the implications of using dname and therefore allowing zones 
other than those described by the draft  and previously served by the as112 
project to be served by as112 project nameservers was fully considered. 
We have requested an additional last call to address this question.

The mechanism specified in 3.2 can be employed in practice by the 
managers of a zone without coordination with as112 server operators.
This facilitates the deployment of additional zones for the purposes of 
authoritative negative answers.


   Many sites connected to the Internet make use of IPv4 addresses that
   are not globally unique.  Examples are the addresses designated in
   RFC 1918 for private use within individual sites.
(Continue reading)

bert hubert | 21 Sep 13:52 2014

fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

Hi everybody,

Your input on the initial implementation described below would be most
appreciated.  I see this as a dns operations issue since it does not
describe an on-the wire change, except when we do AXFR perhaps.  It is
mostly a feature.

However, even features could have interoperability issues, and it would be
nice if we were aligned.

The last forwared paragraph below says "Please let us know your thoughts
based on the semantics outlined above.  Would this work for you?  Do you
miss anything?  Is there a need for multiple ALIAS statements for load
balancing?  Are we needlessly incompatible with existing implementations? 
Is there standardization work we could align against?"



----- Forwarded message from bert hubert <bert.hubert <at>> -----

Date: Sun, 21 Sep 2014 12:54:07 +0200
From: bert hubert <bert.hubert <at>>
To: pdns-users <at>
Subject: [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

Hi everybody,

Based on strong user interest, we are fast-tracking the implementation of
(Continue reading)

internet-drafts | 17 Sep 14:18 2014

I-D Action: draft-ietf-dnsop-dnssec-key-timing-05.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 Working Group of the IETF.

        Title           : DNSSEC Key Rollover Timing Considerations
        Authors         : Stephen Morris
                          Johan Ihren
                          John Dickinson
                          W. (Matthijs) Mekking
	Filename        : draft-ietf-dnsop-dnssec-key-timing-05.txt
	Pages           : 31
	Date            : 2014-09-17

   This document describes the issues surrounding the timing of events
   in the rolling of a key in a DNSSEC-secured zone.  It presents
   timelines for the key rollover and explicitly identifies the
   relationships between the various parameters affecting the process.

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
(Continue reading)

Joe Abley | 16 Sep 17:09 2014

Root Zone KSK Rollover Operations Workshop (save the date)

Hi all,

ICANN will facilitate an open, technical workshop to discuss operational plans for a future root zone KSK
rollover, during the upcoming ICANN 51 meeting to be held in Los Angeles in October 2014.

The workshop is intended for participants who have a technical, operational perspective and is an
opportunity to explore potential options, operational considerations, and other aspects of rolling
the root zone KSK.

The workshop will be held on Thursday October 16, 2014 at the ICANN meeting venue in Los Angeles. This will be
an open event, and remote participation will be available.

More details including a tentative agenda, will be made available soon. If you are able to participate,
please join the ksk-rollover mailing list at
<> which will be used to coordinate this
workshop, and to function as a venue for technical discussion as this work proceeds in the future.


Joe & Roy & Jakob & Duane & Dan
ad-hoc workshop coordinators

DNSOP mailing list
DNSOP <at>

Ondřej Surý | 15 Sep 17:09 2014

RFC 6891 Clarification (EDNS=1 and higher behaviour)

Hey all,

we have received a notice that Knot DNS adds an
answer in case the EDNS=1 (and higher) in the
response where RCODE=BADVERS (and OPT EDNS=0).

The RFC 6891 doesn't forbid such behaviour:

      If a responder does not implement the VERSION level of the
      request, then it MUST respond with RCODE=BADVERS.  All responses
      MUST be limited in format to the VERSION level of the request, but
      the VERSION of each response SHOULD be the highest implementation
      level of the responder.  In this way, a requestor will learn the
      implementation level of a responder as a side effect of every
      response, including error responses and including RCODE=BADVERS.

And in fact we think this might be a more
forward compatible behaviour than returning
an empty response with RCODE=BADVERS.

(Sending it here as dnsext is concluded...)

 Ondřej Surý -- Chief Science Officer
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury <at>
(Continue reading)

Tim Wicinski | 12 Sep 19:20 2014



In Toronto their was an update on the draft dnssec roadblock avoidance, 
  discussion emerged about the various aspects of proxy behavior.   The 
authors stated they were looking for guidance on documenting proxy 
behavior, and the tone of the room was that this type of work should be 

I'd like to start the discussion on getting these issues raised so they 
can be documented.



DNSOP mailing list
DNSOP <at>

Hosnieh Rafiee | 12 Sep 13:27 2014

Review of draft-ietf-dnsop-resolver-priming-04


I reviewed this draft and found it interesting and useful.

Some questions/comments:

Section 3.3 
IPv6 address is 16 octets (bytes) and IPv4 is 4 octets (bytes)

Why the combination of 13 root servers IP4 and IPv6 is  13 * (16 + 28) == 572? What else you considered in the
calculation so that it is 28 octets ? 

"  particular server that appears at all.  In other words: if the
   additional section only has an A RRSet for a server, the resolver
   SHOULD assume that no AAAA RRSet exists.  This is to avoid repeated
   unnecessary queries for names of name servers that do not or not yet
   offer IPv6 service, or, in perspective, will have ceased IPv4

When a new DNS server supports IPv6, when this value is updated in the resolver by the algorithm? Is it in next
query? Because what I understood from the draft, per day, a node only once sends priming query. 

Section 4. 
"  All DNS root name servers need to be able to provide for all
   addresses of all root name servers.  This can easily achieved by
   keeping all root name server names in a single zone and by making all
   root name servers authoritative for that zone."

I am not in DNS operation. But does it really operationally possible (performance or other factors)? I
don't know exactly how many root servers available. 
(Continue reading)

Paul Hoffman | 9 Sep 22:27 2014

The DNSOP document list; request for reviewers

Greetings. Wearing my spiffy new WG Secretary hat (which looks completely different from Suzanne's and
Tim's hats!), I'd like folks to review the WG document list at:

I have a specific request that will hope the WG chairs: Let me know if you're willing to review a document that
has few or no one in the "Reviewers" column. This kind of commits you to read the current draft, to at least
read the diffs of the draft as it progresses, and to do a complete read again during WG Last Call. This
information helps the WG chairs know what drafts should and should not be part of the WG charter.

If you want to discuss any particular draft in the WG, don't respond to this message, of course. Start a new
thread, hopefully with the draft name in it. I'll try to track the level of discussion based on those threads.

Feel free to let me know if you have any secretary-ish questions. Any chair-ish questions ("when will you
move Draft X forwards", "when will the WG LC on Draft Y be over", "can I present Draft X at the next IETF
meeting", ...) go to the chairs or to the list.

--Paul Hoffman
DNSOP mailing list
DNSOP <at>

Tim Wicinski | 9 Sep 21:24 2014

WG Secretary for DNSOP


We've been making good progress on the backlog of documents within 
DNSOP, and because the reward for getting work done within IETF is to be 
given more work, we have a lot of different documents in flight. The 
chairs have been keeping a private spreadsheet of what we feel is the 
work flow, but even we are not infallible.

Paul Hoffman approached us with a plan to help us out as working group 
secretary. In this role, he'll be helping with the administrative and 
process work of the group, under the direction of the chairs, 
particularly with the tasks necessary for clearing ongoing work and 
making sure we're progressing under our new charter. He will be sending 
up an email every other week with the link to the list of documents the 
chairs feel the working group is currently juggling, along with 
reviewers, editors, and some notes of our own. We hope this will help us 
become more efficient with process and more effective with folks 
actually putting in their time on documents.

We expect this will jump start the workflow for the coming months so we 
can continue to clear backlog and give proper attention to new drafts 
and issues.



DNSOP mailing list
(Continue reading)

Hosnieh Rafiee | 7 Sep 17:30 2014

Review request- DNS Secure authentication


I just wonder whether or not any of you had a chance to take a look on the
new version of cga-tsig. If you haven't yet take a look please do it. I
welcome your inputs. 

Do you think the problem statement is clear?



DNSOP mailing list
DNSOP <at>