Paul Hoffman | 26 Oct 00:42 2014

Simplified proposal on helping recursives with long round trip times to the root: draft-wkumari-dnsop-root-loopback

Greetings again. Thank you to the people who gave us feedback on our earlier draft
(draft-wkumari-dnsop-dist-root) saying that it needed a better defined use case and less grandiose
claims of helping where it didn't really. Instead of continuing on that draft, we started a new one with has
the narrower focus, a single goal, and clearer requirements.

Comments are appreciated. If the chairs want, we can talk about this at the upcoming meeting, particularly
if there is discussion here before that.

--Paul Hoffman and Warren Kumari

> A new version of I-D, draft-wkumari-dnsop-root-loopback-00.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-wkumari-dnsop-root-loopback
> Revision:	00
> Title:		Decreasing Access Time to Root Servers by Running One on Loopback
> Document date:	2014-10-25
> Group:		Individual Submission
> Pages:		5
> URL:            http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-root-loopback-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-wkumari-dnsop-root-loopback/
> Htmlized:       http://tools.ietf.org/html/draft-wkumari-dnsop-root-loopback-00
> 
> 
> Abstract:
>   Some DNS recursive resolvers have longer-than-desired round trip
>   times to the closest DNS root server.  Such resolvers can greatly
>   decrease the rount trip time by running a copy of the full root zone
>   on a loopback address (such as 127.0.0.1).  This document shows how
(Continue reading)

Tim Wicinski | 25 Oct 21:43 2014
Picon

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


All

The call period ended earlier this week. The only outspoken nay was 
Peter Koch.  His reasons may prove to be true, as many have said.  But 
the consensus is to adopt the work, and see where it takes us.

The new version has been submitted in the document list. Based on the 
discussion, I've initially labeled the draft 'Experimental', with the 
idea that if the initial research looks promising, this can be changed. 
Actually, this can be changed if there is some larger voice on this.

thanks all
tim

On 10/7/14 12:04 AM, Tim Wicinski 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.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-bortzmeyer-dns-qname-minimisation/
>
> 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.
(Continue reading)

Warren Kumari | 24 Oct 18:01 2014
Picon

Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

Hi all,

This draft has risen from the deep...

It describes a technique that a number of DNS operators use to
surgically / tactically deal with DNSSEC validation failures, for
large-scale outages.

We believe that this is needed -- simply telling customers "This
doesn't work though us, but does work through
$non-validating-competitor because we are better" simply leads to
customers changing to $non-validating-competitor, or operator turning
off DNSSEC for everybody.

I know that there will be some philosophical objections / discussions on this...

W

W

---------- Forwarded message ----------
From:  <internet-drafts <at> ietf.org>
Date: Thu, Oct 23, 2014 at 1:06 PM
Subject: New Version Notification for
draft-livingood-dnsop-negative-trust-anchors-01.txt
To: Ralf Weber <ralf.weber <at> nominum.com>, Jason Livingood
<jason_livingood <at> cable.comcast.com>, Warren Kumari
<warren <at> kumari.net>, Chris Griffiths <cgriffiths <at> gmail.com>, Paul
Ebersman <ebersman-ietf <at> dragon.net>

(Continue reading)

Ray Bellis | 24 Oct 12:09 2014
Picon

Fwd: New Version Notification for draft-bellis-dnsop-connection-close-00.txt

I’ve just posted the following draft:

> A new version of I-D, draft-bellis-dnsop-connection-close-00.txt
> has been successfully submitted by Ray Bellis and posted to the
> IETF repository.
> 
> Name:		draft-bellis-dnsop-connection-close
> Revision:	00
> Title:		Connection Close Signalling for DNS
> Document date:	2014-10-24
> Group:		Individual Submission
> Pages:		5
> URL:            http://www.ietf.org/internet-drafts/draft-bellis-dnsop-connection-close-00.txt

> Status:         https://datatracker.ietf.org/doc/draft-bellis-dnsop-connection-close/

> Htmlized:       http://tools.ietf.org/html/draft-bellis-dnsop-connection-close-00

> 
> 
> Abstract:
>   This document updates [RFC6891] by specifying a new single-bit flag
>   in a DNS response that when seen in a packet carried over a
>   connection-orientated transport protocol indicates to the client that
>   it should close the current connection.

It’s intended as a simple mechanism to improve TCP connection handling that’s far closer to HTTP’s
“Connection: close” semantics than that proposed in draft-wouters-edns-tcp-keepalive.

There are several outstanding questions therein - some relating to TCP state where I don’t know the
technical answer, and a couple where opinions from the WG would be welcomed.  The latter mostly relate to
whether it’s useful to define a request-side semantic for the proposed flag in addition to the
response-side semantics already written.
(Continue reading)

Mwendwa Kivuva | 23 Oct 13:23 2014

Draft Reverse DNS in IPv6 for Internet Service Providers

Refering to the draft by Lee Howard
https://tools.ietf.org/html/draft-howard-dnsop-ip6rdns-00

and given the weakness of the Reverse DNS access for security purposes, what problem is this draft trying to solve? If we need to find the host that has sent an email associated with an address, would we better let DKIM address that without a separate lookup in the receiving server? DKIM detects email spoofing by using digital signature allowing receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators.

Is there a better way to approach the problem?

______________________
Mwendwa Kivuva, Nairobi, Kenya

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-drafts | 22 Oct 22:58 2014
Picon

I-D Action: draft-ietf-dnsop-qname-minimisation-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           : DNS query name minimisation to improve privacy
        Author          : Stephane Bortzmeyer
	Filename        : draft-ietf-dnsop-qname-minimisation-00.txt
	Pages           : 7
	Date            : 2014-10-22

Abstract:
   This document describes one of the techniques that could be used to
   improve DNS privacy (see [I-D.bortzmeyer-dnsop-dns-privacy]), a
   technique called "qname minimisation".

   Discussions of the document should take place on the DNSOP working
   group mailing list [dnsop].

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-00

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:
ftp://ftp.ietf.org/internet-drafts/

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

Bob Harold | 20 Oct 23:03 2014
Picon

Possible slower response with minimization

I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle.

Consider “www.host.group.department.example.com” where the company’s servers are authoritative for the zones:

example.com
department.example.com
group.department.example.com

Without minimization (typical today):

1. Query root for “www.host.group.department.example.com”, get list of “com” servers.
2. Query a com server for “www.host.group.department.example.com”, get list of “example.com” servers.
3. Query an example.com server for “www.host.group.department.example.com”, get answer.

With minimization:

1. Query root for “com”, get list of “com” servers.
2. Query a com server for “example.com”, get list of “example.com” servers.
3. Query an example.com server for “department.example.com”, get list of “department.example.com” servers (which happens to be the same as the list of “example.com” servers).
4. Query a “department.example.com” server (likely the same server as step 3) for “group.department.example.com”, get list of “group.department.example.com” servers.
5. Query a “group.department.example.com” server for “host.group.example.com”, get probably just an A and/or AAAA record, indicating there is no zone cut at that level.
6. Query a “group.department.example.com” server for “www.host.group.department.example.com”, get answer.

Note that it takes twice as many queries, and each depends on the previous, so it is twice as many round trips.

I realize that caching will reduce the extra queries in many cases, but can we estimate the impact of this somehow, to determine if it is significant?

-- 

Bob Harold

DNS hostmaster, University of Michigan

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Peter Koch | 20 Oct 20:37 2014
Picon

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

On Tue, Oct 07, 2014 at 12:04:22AM -0400, Tim Wicinski wrote:

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

I do not support accepting the draft (or the proposal it carries) as a work item.

Other than the author - and obviously others - I believe that the resolution
algorithm of RFC 1034 is pretty clear about the QNAME being sent in full
and that has been operational reality for 25+ years.  A whole system has
been successfully built around it with complex interdependencies.
'parent centric' and 'child centric' resolvers and query patterns
evolved along that algorithm.  The fact that certain services may have experimented
(successfully, to them) with the proposed algorithm already gives anecdotal
evidence at most, but no evidence for the absence of harm.

Making the zone cut, an otherwise arbitrary boundary, a central search
element, is another huge paradigm shift that I see "with great interest".
Please don't anyone tell me that's the case with DNSSEC already - the story
there is different.

Finally, QNAME minimization is providing little gain in the traditional
forward tree and already needs kludges in deeper, nested name spaces.

Comparing the (little) gain with the unclear risk, I'd rather see work and
energy devoted to a long term solution.

-Peter

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

Phillip Hallam-Baker | 20 Oct 20:32 2014

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



On Tue, Oct 7, 2014 at 12:04 AM, Tim Wicinski <tjw.ietf <at> gmail.com> 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.

The draft is available here: https://datatracker.ietf.org/doc/draft-bortzmeyer-dns-qname-minimisation/

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.

yes

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

<nohats>
yes
</nohats>
 
This call for adoption ends Monday 20-October-2014 at 23:59
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Paul Hoffman | 18 Oct 02:15 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
  https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html
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.

In the past two weeks, a few additional people have volunteered to review some of the documents, and a *lot*
of people volunteered to review draft-bortzmeyer-dns-qname-minimisation. It would be grand if more
people would offer to review other documents as well. Also, the documents that are going to be part of the
new DPRIVE WG were removed from the list.

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

--Paul Hoffman, secretary
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

Brian Dickson | 16 Oct 03:58 2014
Picon

Fwd: New Version Notification for draft-dickson-dnsop-spartacus-system-00.txt

Hi, 
This is the second of the pair of drafts submitted together for consideration.
(See the first post for the full description.)
Brian Dickson
---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Wed, Oct 15, 2014 at 6:11 PM
Subject: New Version Notification for draft-dickson-dnsop-spartacus-system-00.txt
To: Brian Dickson <brian.peter.dickson <at> gmail.com>



A new version of I-D, draft-dickson-dnsop-spartacus-system-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:           draft-dickson-dnsop-spartacus-system
Revision:       00
Title:          System to transport DNS over HTTP using JSON
Document date:  2014-10-15
Group:          Individual Submission
Pages:          34
URL:            http://www.ietf.org/internet-drafts/draft-dickson-dnsop-spartacus-system-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dickson-dnsop-spartacus-system/
Htmlized:       http://tools.ietf.org/html/draft-dickson-dnsop-spartacus-system-00


Abstract:
   This is the SPARTACUS DNS gateway system.  It is designed to
   facilitate the transport of DNS messages opaquely, across problematic
   sections of the Internet.  It uses JSON encoding, and HTTP(S) as the
   protocol for transport.

   The main criteria of SPARTACUS is that it preserve DNS messages
   verbatim, and that only properly formatted DNS messages are passed.

   There are two modes (so far) defined: DNS forwarder (dns clients
   point to a local gateway, which forwards to a remote gateway for
   sending to a DNS resolver); and transparent proxy (DNS packets are
   intercepted, passed to a local gateway, which sends them to the
   remote gateway, with original destination IP address etc. encoded,
   and used by the remote gateway as the destination).

   DNS messages are NAT-friendly, so changes to IP or UDP headers do not
   impact them.  Thus, SPARTACUS does not interfere with TSIG, SIG(0),
   or Eastlake Cookies.

   This document describes the system, the components, and behavior,
   with examples.




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.

The IETF Secretariat


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

Gmane