IETF Secretariat | 14 Dec 16:49 2014

Telechat update notice: <draft-ietf-dnsop-dnssec-key-timing-06.txt>

Telechat date has been changed to 2015-01-08 from 2014-12-18
ID Tracker URL:

DNSOP mailing list
DNSOP <at>

Paul Ebersman | 19 Dec 00:56 2014

Call for Presentations - DNS-OARC Spring Workshop, May 2015

Apologies if you are on multiple lists and see multiple copies of this 


The next OARC Spring Workshop will take place in Amsterdam on May 9th
and 10th, the weekend before RIPE70. OARC is requesting proposals for
presentations, with a preference for DDoS attack reports and mitigation
techniques. Reports and field stories can cover DNS-based DDoS attacks,
attacks to DNS infrastructure or side effects suffered by cache resolver

This workshop intends to build from previous strong OARC workshops,
where operational content and research is welcome. Presentations from
DNS operators are particularly welcome, as well as from DNS researchers.
All DNS-related subjects are accepted, introduction to new tools,
visualizations, DNSSEC and novel uses of the DNS.  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. Adopting practice
from other conferences, a timeslot for lighting talks will be available
for short presentations (5 to 10 minutes).

Workshop Milestones
* 18 December 2014, Call for Presentations posted
* 8 January 2015, Open for submissions
* 5 March 2015, Deadline for submission
* 26 March 2015, Final Program published
* 7 May 2015, Final deadline for slideset submission

(Continue reading)

Mukund Sivaraman | 16 Dec 16:25 2014

Review of draft-ietf-dnsop-cookies-00

Hi all

As a part of DNS fragments drafting (which requires protection against
UDP amplification attacks), I reviewed draft-ietf-dnsop-cookies-00. Its
use in fragments would be narrow and I mainly read the draft from that

The draft describes different types of attacks and the COOKIE
mechanisms. While it seems sound, while reading it I felt it didn't
explain well HOW the mechanisms help in preventing the listed attacks,
or HOW the mechanisms should be deployed. This is partly a network
availablity and partly a network integrity related draft, so I think it
needs further descriptions and clarifications. It would be nice for
things that are left to policy have guidelines.

As far as network availability is concerned, compared to what is there
now, the effect of this draft is to deny service to some requests where
service is provided now.

(Another way to look at this would be that in a network without
 possibility of such attacks, this draft's real effect is to improve
 service where service would be disrupted now. Nevertheless, the draft
 is written to assist the server in dropping or refusing requests that
 don't satisfy some conditions, and so the earlier point is considered.)

The conditions for such denial must be described clearly, and perhaps,
not completely left to operators to decide.

(Continue reading)

internet-drafts | 16 Dec 02:15 2014

I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.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           : Definition and Use of DNSSEC Negative Trust Anchors
        Authors         : Paul Ebersman
                          Chris Griffiths
                          Warren Kumari
                          Jason Livingood
                          Ralf Weber
	Filename        : draft-ietf-dnsop-negative-trust-anchors-00.txt
	Pages           : 17
	Date            : 2014-12-15

   DNS Security Extensions (DNSSEC) is now entering widespread
   deployment.  However, domain signing tools and processes are not yet
   as mature and reliable as those for non-DNSSEC-related domain
   administration tools and processes.  Negative Trust Anchors
   (described in this document) can be used to mitigate DNSSEC
   validation failures.

The IETF datatracker status page for this draft is:

There's also a htmlized version 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)

Paul Hoffman | 15 Dec 21:42 2014

Nudging some reviews

Greetings again. There are many WG documents that could be being discussed. shows the following as active:


Each of these has at least a few folks who volunteered to send comments. Even if you aren't one of the people
who volunteered for a particular draft, but particularly if you are, maybe spend a bit of time this week and
comment on at least two of the above. Your comments might cause more comments, and so on. This helps get
documents prepared for WG Last Call sooner.

--Paul Hoffman
DNSOP mailing list
DNSOP <at>

KSK Rollover SOI | 12 Dec 20:09 2014

Solicitation for Statements of Interest regarding Root KSK Rollover

ICANN, as the IANA functions operator, in cooperation with Verisign as the
Root Zone Maintainer and the National Telecommunications Information
Administration (NTIA) as the Root Zone Administrator, together known as
the Root Zone Management (RZM) partners, seek to develop a plan for
rolling the DNS root zone key-signing key (KSK). The KSK is used to sign
root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the
Internet’s root zone. The Root Zone Partners are soliciting five to seven
volunteers from the community to participate in a Design Team to develop
the Root Zone KSK Rollover Plan (“The Plan”). These volunteers along with
the RZM partners will form the Design Team to develop The Plan.

Individuals interested in volunteering approximately 5 hours per week for
the Design Team should consult the announcement:

and submit their Statement of Interest to ksk-rollover-soi <at> no
later than January 16, 2015.

DNSOP mailing list
DNSOP <at>
Joe Abley | 10 Dec 17:41 2014

Re: Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

On 7 Oct 2014, at 00:04, Tim Wicinski <tjw.ietf <at>> wrote:

> Dear DNSOP WG,
> After discussions about the landing spot of this document, DNSOP vs the newer DNS Privacy WG, it was
realized the updated DNSOP charter specifically had work like this in mind.
> This starts a Call for Adoption for draft-bortzmeyer-dns-qname-minimisation.

Support adoption, will review/contribute (regardless of how unlikely that sounds to people who have been
waiting for me to come up for air for the past several months).


DNSOP mailing list
DNSOP <at>

Paul Vixie | 9 Dec 02:16 2014

hong kong workshop, day 2, live link


draft agenda:


Paul Vixie

DNSOP mailing list
DNSOP <at>

Mukund Sivaraman | 8 Dec 09:32 2014

Application level DNS message fragmentation

Hi all

[I am reluctant to send this, as it could very well be a stupid
 idea. But as at least one person has suggested I discuss it on DNSOP,
 so here it is.]

When a server (plain or EDNS capable) is queried via UDP, and determines
that the response won't fit into 512 (plain) or the client's UDP message
size (EDNS), it sets TC=1 forcing the client to retry via TCP.

Fragmentation at the IP layer causes issues. Fragmentation could occur
when the PMTU is lower than the advertised EDNS message size. IP
fragments may be dropped by devices on the path causing the UDP datagram
to not arrive at the user application. Packets with DF=1 also are not
fragmented by a router if it cannot forward it.

With EDNS, when the client message size is small, a response may still
not fit in a single datagram causing the client to retry using TCP.


Can we have the following scheme so that fragmentation is supported at
the application level?

When a server determines that the response doesn't fit into a single
datagram (512 or the client's message size), the server splits the reply
into multiple fragment datagrams (512 or some discovered PMTU that
works) such that:

1. Each datagram is a DNS reply message with identical header field
(Continue reading)

DraftTracker Mail System | 8 Dec 09:09 2014

Last Call Expired: <draft-ietf-dnsop-dnssec-key-timing-06.txt>

Please DO NOT reply to this email.

I-D: <draft-ietf-dnsop-dnssec-key-timing-06.txt>
ID Tracker URL:

IETF Last Call has ended, and the state has been changed to
Waiting for Writeup.

DNSOP mailing list
DNSOP <at>

Paul Vixie | 8 Dec 02:06 2014

workshop on dns future root service architecture (hong kong) is starting

we're starting shortly.

live broadcast:


jabber room:

xmpp:wdfrs <at>

the presentations will be put on youtube for later watching, for those
now sleeping.


Paul Vixie

DNSOP mailing list
DNSOP <at>