internet-drafts | 17 Sep 14:18 2014
Picon

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

Abstract:
   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:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-key-timing-05

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

Joe Abley | 16 Sep 17:09 2014
Picon

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
<https://mm.icann.org/mailman/listinfo/ksk-rollover> which will be used to coordinate this
workshop, and to function as a venue for technical discussion as this work proceeds in the future.

Regards,

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

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

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...)

Cheers,
--
 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> nic.cz    http://nic.cz/
 -------------------------------------------
(Continue reading)

Tim Wicinski | 12 Sep 19:20 2014
Picon

draft-ietf-dnsop-dnssec-roadblock-avoidance


All,

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 
included.

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

Thanks
tim

References:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/
https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-01

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Hosnieh Rafiee | 12 Sep 13:27 2014

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

Hi,

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
   service."

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:

http://svn.tools.ietf.org/svn/wg/dnsop/doclist.html

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> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Tim Wicinski | 9 Sep 21:24 2014
Picon

WG Secretary for DNSOP

All

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.

thanks

tim
suzanne

_______________________________________________
DNSOP mailing list
(Continue reading)

Hosnieh Rafiee | 7 Sep 17:30 2014

Review request- DNS Secure authentication

Hello,

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? 

http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-10

Thanks,

Best,
Hosnieh

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

internet-drafts | 4 Sep 00:23 2014
Picon

I-D Action: draft-ietf-dnsop-child-syncronization-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 Working Group of the IETF.

        Title           : Child To Parent Synchronization in DNS
        Author          : Wes Hardaker
	Filename        : draft-ietf-dnsop-child-syncronization-03.txt
	Pages           : 13
	Date            : 2014-09-03

Abstract:
   This document specifies how a child zone in the DNS can publish a
   record to indicate to a parental agent that the parental agent may
   copy and process certain records from the child zone.  The existence
   of the record and any change in its value can be monitored by a
   parental agent and acted on depending on local policy.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-child-syncronization-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-child-syncronization-03

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

internet-drafts | 3 Sep 23:28 2014
Picon

I-D Action: draft-ietf-dnsop-dnssec-roadblock-avoidance-01.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 Roadblock Avoidance
        Authors         : Wes Hardaker
                          Olafur Gudmundsson
                          Suresh Krishnaswamy
	Filename        : draft-ietf-dnsop-dnssec-roadblock-avoidance-01.txt
	Pages           : 16
	Date            : 2014-09-02

Abstract:
   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 approache to detect and overcome
   network issues that a DNSSEC software/system may face.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-01

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

rfc-editor | 3 Sep 02:10 2014

RFC 7344 on Automating DNSSEC Delegation Trust Maintenance

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

        
        RFC 7344

        Title:      Automating DNSSEC Delegation Trust Maintenance 
        Author:     W. Kumari, O. Gudmundsson, G. Barwood
        Status:     Informational
        Stream:     IETF
        Date:       September 2014
        Mailbox:    warren <at> kumari.net, 
                    ogud <at> ogud.com, 
                    george.barwood <at> blueyonder.co.uk
        Pages:      18
        Characters: 39434
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-dnsop-delegation-trust-maintainance-14.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7344.txt

This document describes a method to allow DNS Operators to more
easily update DNSSEC Key Signing Keys using the DNS as a
communication channel.  The technique described is aimed at
delegations in which it is currently hard to move information from
the Child to Parent.

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

INFORMATIONAL: This memo provides information for the Internet community.
(Continue reading)


Gmane