Paul Vixie | 17 Nov 23:23 2014

Re: Call for Adoption draft-wkumari-dnsop-root-loopback

Monday, November 17, 2014 2:16 PM

That seems like something that should be fixable in BIND, yes? (And thanks for doing that testing, btw)

it's not broken. dnssec has no facility for validating data at slave synchronization time (after each axfr or ixfr or rsync). this isn't a bind-ism. validation is defined to happen at consumption time.

Paul Vixie
DNSOP mailing list
DNSOP <at>
Tim Wicinski | 16 Nov 22:45 2014

Call for Adoption draft-wkumari-dnsop-root-loopback

This starts a Call for Adoption for draft-wkumari-dnsop-root-loopback

The draft is available here:

Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

We will take all adoption support from Warren's email.

This official call for adoption ends Sunday, November 30th, 2014.

tim wicinski
DNSOP co-chair

DNSOP mailing list
DNSOP <at>

internet-drafts | 16 Nov 08:41 2014

I-D Action: draft-ietf-dnsop-edns-client-subnet-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           : Client Subnet in DNS Requests
        Authors         : Carlo Contavalli
                          Wilmer van der Gaast
                          David C Lawrence
                          Warren Kumari
	Filename        : draft-ietf-dnsop-edns-client-subnet-00.txt
	Pages           : 23
	Date            : 2014-11-15

   This draft defines an EDNS0 extension to carry information about the
   network that originated a DNS query, and the network for which the
   subsequent reply can be cached.


   [RFC Editor: Please remove this note prior to publication ]

   This informational document describes an existing, implemented and
   deployed system.  A subset of the operators using this is at . The authors believe
   that it is better to document this system (even if not everyone
   agrees with the concept) than leave it undocumented and proprietary.

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

Internet-Drafts are also available by anonymous FTP at:

DNSOP mailing list
DNSOP <at>

Francis Dupont | 15 Nov 22:48 2014

review of draft-dickinson-dnsop-5966-bis-00.txt

Some comments:
 - 4 page 5: "It (TCP)
   SHOULD NOT be used only for zone transfers and as a fallback."

  this SHOULD NOT is very hard to implement without dubious
  interpretations (i.e., the idea is right but the current wording
  could lead to unexpected/unwanted results).

 - 5 page 4: "both clients and servers SHOULD support connection reuse"
  this should not be applied to servers as they MUST use the same
  connection than queries are received (cf last statement of 4 page 5).
  IMHO this is mainly a wording issue.

 - 5 page 6: the last statement of RFC 5966 was removed, perhaps
  because it could be applied to the TCP fast open?

 - 5 page 5-6: a problem is not covered: what a server should do when
  a client closes the TCP connection before pending responses are
  sent. I.e., what to specify for the server side of lack of connection
  signaling? Note the new 6 page 5 makes this more likely.

 - 6 page 5: either the should for parallel processing has to be upper
  case or another word has to be used. Note the new 7 uses a RECOMMENDED
  key word for a statement including this.

 - 8 page 7: IMHO 8 (TCP Fast Open) should be dropped or moved.

 - 9 page 7: please move this section (summary of pros and cons)
  in an appendix as it is clearly not normative.

 - 11 page 9: I am repeating what I said at the mic: if we don't allow
  servers to close TCP connections with any timeout, including 0 seconds,
  we'll open servers supporting TCP (so all servers :-) to easy DoS


Francis.Dupont <at>

DNSOP mailing list
DNSOP <at>

Tim Wicinski | 15 Nov 01:04 2014

Call for Adoption: draft-dickinson-dnsop-5966-bis

This starts a Call for Adoption for draft-dickinson-dnsop-5966-bis

The draft is available here:

Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends Saturday November, 29th, 2014

tim wicinski
DNSOP co-chair

DNSOP mailing list
DNSOP <at>

Tim Wicinski | 15 Nov 01:00 2014

Action Items from IETF91

Action Items

Here is a summary from the minutes for the DNSOP meeting on action items 
for everything that has been discussed.

These will start going out every few days, to not overwhelm the group 
nor the chairs.

If anyone objects please speak up.

tim and suzanne

Call for Adoption

Working Group Last Call:

More work/discussion needed:
	draft-bellis-dnsop-connection-close vs. draft-ietf-dnsop-tcp-keepalive

Assistance in completing:

DNSOP mailing list
DNSOP <at>

Tony Finch | 14 Nov 11:42 2014

Re: Fwd: New Version Notification for draft-wkumari-dnsop-root-loopback-01.txt

So I have adjusted the configuration on my workstation's name server to
include the global root servers (for robustness) as well as a local
stealth slave (for low latency). Here's a count of queries directed at the
root zone and the servers chosen to handle them. I wonder how different it
would be if I had worse connectivity...

 115 ::1#53
  15 2001:500:1::803f:235
  20 2001:500:2::c
  14 2001:500:2d::d
   8 2001:500:2f::f
  14 2001:500:3::42
  12 2001:500:84::b
  60 2001:503:ba3e::2:30
  36 2001:503:c27::2:30
  14 2001:7fd::1
  17 2001:7fe::53
  40 2001:dc3::35


f.anthony.n.finch  <dot <at>>
Southwest Viking: Southeasterly 7 to severe gale 9. Rough or very rough.
Occasional drizzle. Moderate or good.

DNSOP mailing list
DNSOP <at>

Paul Vixie | 14 Nov 10:14 2014

Workshop on DNS Future Root Service Architecture (2014 WDFRSA), Hong Kong, December 8-9, 2014

Registration is now open for the 2014 Workshop on DNS Future Root Service Architecture (2014 WDFRSA)

> Location: Hong Kong, HK
> Venue: The Mira Hotel (Kowloon district)
> Date: December 8-9, 2014
> Hosted by: ISOC-HK
> Sponsors: ZDNS/BII and CNNIC
> Co-chairs: Warren Kumari and Paul Vixie
This two day workshop will focus on the DNS root service architecture issues raised by two current Internet Drafts:1.
   Decreasing Access Time to Root Servers by Running One on Loopback
   W. Kumari, Ed.; P. Hoffman

   How to scale the DNS root system?
   Xiaodong Lee; Paul Vixie; Zhiwei Yan
At the time of this writing the DNS serves more than two billion people and more than five billion connected devices, with more to come due to expected growth in mobile, in Things, and in new connected users. The DNS root service architecture still resembles the way it was when there were just a few hundred hosts thirty years ago, although it is now more widely distributed.Reachability of the DNS root zone content by a diverse collective of recursive DNS servers is a vital go/no-go condition for all Internet traffic. Extended outages which isolate a network from DNS root zone content are effectively complete outages for that network, making access to the DNS root zone information a vital enabler for human discourse and commerce.
We wish to make root zone content as reachable and as resilient as it can be made without risking complexity collapse. Two extant proposals involve changes to RDNS configuration, and possibly also changes to routing, to addressing, and to root zone metadata. These proposals do not conflict with each other, but the operational results of deploying each would be quite different.After the workshop, the various proponents will have new information to include in their proposals, and there will be a greater understanding of the various points of agreement and disagreement about how the community can move forwards. --- Agenda: Monday: 0900-0910: Welcome from ISOC-HK (local host) 0910-0915: Welcome from ZDNS/BII (sponsor) 0915-0920: Welcome from CNNIC (sponsor) 0920-0930: Logistics and late agenda changes (co-chairs) 0930-0945: Current problem statement (co-chairs) 0945-1030: Decreasing Access Time to Root Servers by Running One on Loopback (W. Kumari, P. Hoffman) (present current draft, field questions and objections, propose text or logic revisions) 1030-1100: Break (coffee) 1100-1145: How to scale the DNS root system? (X. Li, P. Vixie) (present current draft, field questions and objections, propose text or logic revisions) 1145-1230: Open discussion of the two drafts, with expected refinements to the problem statement 1230-1400: Lunch (hosted) 1400-1430: Testbed for IPv6-only DNS development (Dr. Linjian Song, BII Lab) 1430-1500: Evolution of DNS root zone operation and management (Dr. Declan Ma, ZDNS Lab) 1500-1530: AS112 as an example of unowned anycast at scale (B. Manning, P.Vixie, J. Abley, W. Maton) 1530-1700: Open (proposals welcome, workshop participants to decide in the moment) 1700-1900: (unscheduled private time) 1900-2200: Dinner (hosted) Tuesday: 0900-0930: Summary of day 1, closed issues, opened issues (co-chairs) 0930-1030: Summary of changes to text of Internet Drafts accepted during workshop 1030-1100: Break (coffee) 1100-1230: Open (proposals welcome, workshop participants to decide in the moment) 1230-1400: Lunch (hosted) --- Workshop Logistics:
Travel support including round trip coach air fare, taxi fare, meals, and a room at the venue hotel (The Mira Hotel, Kowloon district, Hong Kong) will be offered to participating root name server operators, authors of each of the two Internet Drafts to be discussed, and IETF DNSOP Working Group co-chairs. The workshop will also be open to any interested party, and every effort will be made to both stream and store all presentations (via YouTube). There is no cost for attending the workshop. Pre-registration is required.

Information on how to register and on the proposed agenda will be sent shortly to this same distribution. For travel planning purposes, the meeting will run all day on December 8, with a social event that evening, and for half a day on December 9, finishing immediately after lunchtime. Participants are invited to submit proposals for several open slots, with final selection to be made during the workshop itself.

To register for this workshop, please e-mail to the co-chairs:
    Warren Kumari <warren <at>>, Paul Vixie <paul <at>>
...indicating your primary affiliation (root server operator, DNSOP WG co-chair, draft co-author, interested party), and your needs (if any) regarding travel support to attend the workshop. Note that to qualify for travel support you must room at the venue hotel, using our reservation code. If you wish to propose a topic for one of the open agenda slots, you may do so at any time, up to and including the moment of the workshop itself.

We have a room block at venue hotel. To reserve a room in this block, visit the URL shown below:

Warren Kumari
Paul Vixie
DNSOP mailing list
DNSOP <at>
Tim WIcinski | 14 Nov 03:55 2014

Call for Adoption: draft-eastlake-dnsext-cookies


This starts a call for adoption for draft-eastlake-dnsext-cookies.

The draft is available here:

Please review this draft to see if you think it is suitable for adoption 
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends Thursday, November 27th, 2014.

(Yes, I know this is the American Holiday. However, this draft has been 
discussed several times, and in a previous meeting the room was 
unanimous that the draft be adopted, and this chair failed to send the 
email to start the formal process.)


DNSOP mailing list
DNSOP <at>

Warren Kumari | 13 Nov 22:20 2014

Requesting adoption of draft-wkumari-dnsop-root-loopback

Dear DNSOP Chairs,

We are requesting a call for adoption of draft-wkumari-dnsop-root-loopback.


A new version of I-D, draft-wkumari-dnsop-root-loopback-01.txt
has been successfully submitted by Paul Hoffman and posted to the
IETF repository.

Name:           draft-wkumari-dnsop-root-loopback
Revision:       01
Title:          Decreasing Access Time to Root Servers by Running One
on Loopback
Document date:  2014-11-11
Group:          Individual Submission
Pages:          7

   Some DNS recursive resolvers have longer-than-desired round trip
   times to the closest DNS root server.  Such resolvers can greatly
   decrease the round trip time by running a copy of the full root zone
   on a loopback address (such as  This document shows how
   to start and maintain such a copy of the root zone in a manner that
   is secure for the operator of the recursive resolver and does not
   pose a threat to other users of the DNS.


I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.

DNSOP mailing list
DNSOP <at>

Olafur Gudmundsson | 12 Nov 05:29 2014

Automating Provision of DS Records

Hi, as I mentioned at the mike:  For those at the IETF-91 I will be hosting a Beach Bof for people that are interested in working on creating an automated solution to this problem in as short time as possible. Send me an email if you are interested Time: 15:00 <at> Thursday Loaction: TBD Olafur Call to Action: Automating Provision of DS Records to DNS Parents Background The DNS ecosystem is complex and problematic. Because there are many relationships between domains and their “DNS parent”, and these relationships are often convoluted, updating information for the parent is difficult. This blog post will explore this issue in an effort to highlight the need for an automated mechanism to inject DNS delegation information into Parent DNS. To get an idea of the convoluted nature of the DNS ecosystem, it will be helpful to start with an example: If we were to sign the domain “ ”, the parent of this domain is “com”. However, .com is what’s known as a “shared registration delegating domain following the ICANN rules”. This means that the holder or owner of “”, known as Registrant, purchased or leased the domain from a Registrar or a Reseller authorized to market domain names in .com. After the Registrant pays for the domain, the Registrar updates a common database called a Registry. The Registry holds information about the Registrant, Registrar, and DNS servers for the domain. This information is kept in a database operated by the Registry Operator. Registry Operators also operate (or contract out) the DNS servers that list the registered domains. In most cases, the Registrant has a single account with the Registrar for all its domains. However, there are three “handles” listed in the account: Registrant, Admin, and Tech. And there are different ways that DNS for the domain is handled: - The DNS can be handled by the Registrant - The Registrar can operate DNS (This is common when the domain is registered and operations are then moved.) - The Registrant can outsource the operation to a company like CloudFlare For the three different kinds of DNS operators listed above, the difficulty of changing information in the parent differs greatly. For the Registrant, the process is fairly simple: they will need to log into their account and change the information manually. Registrars can simply inject changes via the programmatic interface they use to update the Registry. In the case of third party operator like CloudFlare, it becomes a bit more difficult. Third party operators need the Registrant to either hand over access to the Registration account, or ask Registrant to pass information on---both of those options have many potential problems. To make matters worse, in many cases the third party operator has no information on who the entity acting as a registrar for the domain is, or how to contact them. Even if the DNS operator knows about the registrar, it may not have any authority to make changes. CloudFlare currently operates between 1-2 Million DNS domains for its customers as a third party DNS operator. These registrations are in over 400+ TLD’s, and in unknown number of sub-delegation domains like “”. In only a few cases do we have access to domain registration accounts because we are treated as unknown entity by Registrars and Resellers. When we want DNS information changed, we need the Registrant to relay that information, and the only time an registrant is motivated to log into his or her registration account on our behalf is when we become the DNS operator, or when DNS operation is moved away from us. Our Goal: An Automated Solution to Update DNS Leveraging DNSSEC. We would like to create a system where CloudFlare, and any other third party DNS operators, can update the delegation DNS information in the parent domains in a 100% automated manner. In the current registrations system, we can, in theory, find out who the Registrar is via a WHOIS query. But, in many cases, the WHOIS query fails, or the information from that query is not relevant. It might only return the name of Registrar, Address of registrar, phone number, or even just a email address. We are looking for ways to discover the correct entity that needs to be contacted to insert the change into parent zone, or find out that there is no such capability. In order to make this happen wwe want to leverage RFC7344 <> and DANE like <>technologies to build a solution that is easy to manage, easy to operate, and is secure. Path forward: What are the Missing Pieces? There are three different problems that need to be addressed: 1. Protocols for expressing to “parent representative/agent” what needs to be changed for a specific domain 2. Protocols for finding the “Parent agent” delegation automation server, i.e., to be able to send message via the protocol developed for a to the appropriate party. 3. Creating trust in the information in the child zone thus it can be moved into the parent zone. Problem a is a simple definition of what data is submitted as a request. The server contacted might be right one or one that issues a referral to another server. Problem b is by far the most difficult one due to the complexities of relationships involved. There are a number of different ways this can be done. Problem c has to large extent been solved for DNSSEC signed zones by RFC7433 <>, but there is a missing element: establishing initial trust. At the end of the day, the DNS operator wants a simple answer an URL for parental server or statement saying “Not available”. Problems a and c are best addressed by technical proposals in industry forums, but finding the registrar is a much harder problem unless we can get all parties in the registration industry to cooperate. Call to Action CloudFlare is willing to take the lead on creating a proposed solution, and demonstrating the solution. The solution will be public and any tools we create as part of the demonstration will be made available as open source. We are looking for few interested parties to team up with us and having a demonstration ready in few months.

DNSOP mailing list
DNSOP <at>