[DNSOP] Decreasing Access Time to Root Servers

[Jiankang Yao]

Hello,


It is good to know that draft-ietf-dnsop-root-loopback will be soon be 
published as RFC.
Thanks for authors' and WG's  effort. 


For the rfc-to-be (draft-ietf-dnsop-root-loopback-05.txt), there are following 
working group summary
"
This document came out of several different proposals involving
improving the redundancy of the DNS Root Zone.  The document was the
one which the Working Group was able to gather consensus.  The
discussion behind this was engaging as several felt the trade off of
local copies for speed increased operational fragility.  This document
was not written to become a Best Practice or an Internet Standard, but
as an Informational document to explain how operators currently manage
such tasks."

draft-yao-dnsop-root-cache helps to provide another or alternative choices to 
improve the redundancy of the DNS Root Zone.
Different dns operators may choose different methods:  
draft-ietf-dnsop-root-loopback  or draft-yao-dnsop-root-cache.
draft-yao-dnsop-root-cache improves on draft-ietf-dnsop-root-loopback in the 
following ways:
1.  The resolver which supports draft-yao-dnsop-root-cache is still a resolver 
which still needs to get the root data information from 13 dns root servers.
The resolver which supports draft-ietf-dnsop-root-loopback does not need to 
get the root data information from 13 dns root servers. In the other words, 
 if all resolvers were upgraded to support draft-ietf-dnsop-root-loopback, 
there would have millions of "root servers". It is hard to imagine how to 
manage so many "root servers".  The root-cache-enabled resolver has not such 
problems.

2. Root-loopback server Operation of the Root Zone  must be run on the Loopback 
Address while the root-cache-enabled resolver can be run on any address. 

3. The resolver which supports draft-yao-dnsop-root-cache will cache and 
improve the recent query result (which is also most likely to be queried again) 
via the new mechanism, improving the dns query efficiency. 

4. Due to the possible "operational fragility", the root-loopback enabled 
software will be released without the default configuration of support of 
draft-ietf-dnsop-root-loopback.  The root-loopback enabled software is suitable 
for the experienced DNS operators and big dns 
resolving service providers.  
The root-cache enabled software can be released with the default configuration 
of support of draft-yao-dnsop-root-cache.  The root-cache enabled software is 
suitable for most DNS operators and dns 
resolving service providers.  


To help to decrease the access time to root servers, one method might be not 
enough to satisfy all kinds of DNS operators.
It is better that the WG provides another choice for dns operators.

Thanks.



Jiankang Yao

From: The IESG
Date: 2015-10-06 07:03
To: IETF-Announce
CC: dnsop mailing list; dnsop chair; RFC Editor
Subject: [DNSOP] Document Action: 'Decreasing Access Time to Root Servers by 
Running One on Loopback' to Informational RFC 
(draft-ietf-dnsop-root-loopback-05.txt)
The IESG has approved the following document:
- 'Decreasing Access Time to Root Servers by Running One on Loopback'
  (draft-ietf-dnsop-root-loopback-05.txt) as Informational RFC

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

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/





Technical Summary

   Some DNS recursive resolvers have longer-than-desired round trip
   times to the closest DNS root server.  Some DNS recursive resolver
   operators want to prevent snooping of requests sent to DNS root
   servers by third parties.  Such resolvers can greatly decrease the
   round trip time and prevent observation of requests by running a copy
   of the full root zone on a loopback address (such as 127.0.0.1).
   This document shows how to start and maintain such a copy of the root
   zone that does not pose a threat to other users of the DNS, at the
   cost of adding some operational fragility for the operator.

Working Group Summary

This document came out of several different proposals involving
improving the redundancy of the DNS Root Zone.  The document was the
one which the Working Group was able to gather consensus.  The
discussion behind this was engaging as several felt the trade off of
local copies for speed increased operational fragility.  This document
was not written to become a Best Practice or an Internet Standard, but
as an Informational document to explain how operators currently manage
such tasks.

Document Quality

Note, 

There is an IPR disclosure related to this document.  The Authors have
already been aware of this IPR disclosure, and no of no other IPR
disclosure related to this document.  The opinion of the working group
is that the IPR party implies a willingness to commit to not requiring
any licenses or royalties.

Personnel

The Document Shepherd is Tim Wicinski. 

Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views

[Petr Spacek]

On 25.8.2015 17:34, Petr Spacek wrote:
> On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>>> On Feb 11, 2015, at 11:24 AM, Petr Spacek  wrote:
> [...]
>>> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how 
>>> to
>>> improve usability without sacrificing security.
>>>
>>>
>>> Disclaimer
>>> ==
>>> Method described below is covered by US patent application named "USING 
>>> DOMAIN
>>> NAME SYSTEM SECURITY EXTENSIONS IN A MIXED-MODE ENVIRONMENT".
>>>
>>> See Red Hat, Inc. Statement of Position and Our Promise on Software Patents:
>>> http://www.redhat.com/legal/patent_policy.html
>>>
>>>
>> I reject the below text as I do not want any IPR on anything in this 
>> informational document. 
>> Olafur
> 
> Olafur and dnsop chairs,
> 
> would you be willing to accept the text below if Red Hat granted a license
> similar to https://datatracker.ietf.org/ipr/1430/ ?
> (I.e. the patent could be asserted only for defensive purposes.)
> 
> I'm asking because the text might be suitable for some other document
> describing split-dns, so this question is still valid even if the text might
> not be directly usable in draft-ietf-dnsop-dnssec-roadblock-avoidance.
> 
> Thank you for considering this as an option.

I'm sorry for nagging you again, but we are still interesting in knowing if
proposed approach how to deal with patent issue would be acceptable to dnsop.

Thank you very much,
Petr Spacek  @  Red Hat

> Petr Spacek @ Red Hat
> 
>>> The Hack
>>> 
>>> Fundamental assumption:
>>> Internal & external DNS view are both signed with the same keys or both
>>> unsigned. This assumption allows the method to work without explicit
>>> configuration on every client and removes dependency on reliable/secure
>>> network-detection logic.
>>>
>>>
>>> The main idea can re-phrased as amendment to section 5 of the draft:
>>>
>>>   The general fallback approach can be described by the following
>>>   sequence:
>>>
>>>   If the resolver is labeled as "Validator" or "DNSSEC aware"
>>>   Send query through this resolver and perform local
>>>   validation on the results.
>>>
>>>   If validation fails, try the next resolver
>>>
>>>   Else if the resolver is labeled "Not a DNS Resolver" or
>>>  "Non-DNSSEC capable"
>>>   Mark it as unusable and try next resolver
>>>
>>> --- amended text begins here ---
>>>
>>>   Else if no more resolvers are configured and if direct queries
>>>   are supported
>>>  1. Try iterating from Root
>>>
>>>  2. If the answer is SECURE/BOGUS
>>>Return the result of iteration.
>>>
>>>  3. If the answer is INSECURE
>>>Re-query "Non-DNSSEC capable" servers and get answer
>>>from "Non-DNSSEC capable" servers.
>>>Set AD bit to 0 before returning the answer to client.
>>>
>>>   Else return a useful error code
>>>
>>>
>>> This method covers DNS split-views with internal unsigned views pretty
>>> nicely as long as the fundamental assumption holds. (Naturally it works only
>>> for cases where fallback to iteration is possible.)
>>>
>>> We wanted to write Unbound module for this but it is harder than it seems.
>>> (Proof-of-concept with stand-alone DNS proxy works fine, we have problem 
>>> with
>>> Unbound module architecture - not with the described method.)
>>>
>>> Feel free to incorporate the idea to the draft if you wish.
>>>
>>> -- 
>>> Petr Spacek  @  Red Hat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-tcp-keepalive

[神明達哉]

On Mon, Oct 5, 2015 at 1:08 PM, Tim WIcinski  wrote:

> This starts a Working Group Last Call  for
> draft-ietf-dnsop-edns-tcp-keepalive

> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/
>
> The chairs feel the authors have spent considerable time addressing
> questions and issues raised, and the current document has undergone some
> solid revision.  We would appreciate if the working group could review the
> draft and offer relevant comments. Also, if someone feels the document is
> *not* ready for publication, please speak out with your reasons.

I've read the 03 version of draft.  It's very well written and I've
not found any critical technical issues.  So I basically think it's
ready to ship.

I have a couple of minor comments, which the authors might want to
address/discuss before advancing the draft:

1. Section 3.2.1

   DNS clients MAY include the edns-tcp-keepalive option in the first
   query sent to a server using TCP transport to signal their desire to
   keep the connection open when idle.

  I wonder whether we want to explicitly say something about including
  the edns-tcp-keepalive option in subsequent queries on the same TCP
  connection.  Although such behavior isn't explicitly prohibited, the
  following part of Section 3.4 seems to rather expect such subsequent
  inclusion more commonly:

   Since servers must be faithful to this specification even on a
   persistent TCP connection it means that (following the initial
   exchange of timeouts) a server may not be presented with the
   opportunity to signal a change in the idle timeout associated with a
   connection if the client does not send any further requests
   containing EDNS0 OPT RRs.

  So it may be better to explicitly say, e.g., that clients MAY
  include the option in subsequent queries.  We might even want to use
  a stronger requirement like "the client SHOULD occasionally include
  the option in subsequent queries if it includes the option in the
  first query".

2. Section 3.2.2

   A DNS client that receives a response that includes the edns-tcp-
   keepalive option with a TIMEOUT value of 0 should send no more
   queries on that connection and initiate closing the connection as
   soon as it has received all outstanding responses.

  I wonder whether this 'should' may better be 'SHOULD'.  I personally
  don't have a strong opinion, but it seemed to be more consistent
  with other use of the RFC2119 keywords in this document.

And, one minor editorial nit: In Section 5

   [...]  When a Nameserver
   detects abusive behaviour, it SHOULD immediately close the TCP
   connection and free the resources used.

  Perhaps s/Nameserver/nameserver/?  Or, it might even be "DNS server"
  ('[Nn]ameserver' or 'name server' doesn't seem to be used anywhere
  else in the document).

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop