Paul Hoffman | 23 Jul 05:18 2016

Review of draft-ietf-dprive-dtls-and-tls-profiles-03

This document seems ready for WG Last Call. The comments I have hear can 
be dealt with before or during WG Last Call.

--Paul Hoffman

=====

The following text from section 4.2 still seems wrong:
    Since Strict Privacy provides the strongest privacy guarantees it is
    preferable to Opportunistic Privacy.
Strict Privacy is only preferable to users who would rather have an 
unusable Internet connection: an Internet connection where every DNS 
lookup in every application fails. Currently, that size of that set of 
users is incredibly small, although it might grow over time. The 
sentence above could lead developers to implement Strict Privacy without 
also implementing Opportunistic Privacy to the detriment of the vast 
majority of current Internet users.

Proposed replacement:
    Strict Privacy provides the strongest privacy guarantees and 
therefore should always be implemented along with Opportunistic Privacy. 
The negative implications of the two types of privacy are so radically 
different (a possibly-unusable Internet service for Strict Privacy; 
complete control of DNS responses for Opportunistic Privacy) that 
neither option can be considered a good default for all users.

=====

I have a significant concern about the discussion of 
draft-ietf-dprive-dnsodtls, which is listed as an informational 
(Continue reading)

Tim Wicinski | 23 Jul 03:39 2016
Picon

Call for Adoption: draft-bellis-dnsop-session-signal

I know we've just started talking about this, and the authors are still 
sorting out a few things, but the sense of the room we received was to 
adopt it, work on it, etc.

It appears they have simplified it in the -01 version.

This starts a Call for Adoption for draft-bellis-dnsop-session-signal

The draft is available here:
https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/

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.

With this being the summer, we're going to run a 3 week call for adoption.

This call for adoption ends: Thursday, 12 August 2016

Thanks,
tim wicinski
DNSOP co-chair

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

(Continue reading)

internet-drafts | 21 Jul 18:48 2016
Picon

I-D Action: draft-bellis-dnsop-session-signal-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 of the IETF.

        Title           : DNS Session Signaling
        Authors         : Ray Bellis
                          Stuart Cheshire
                          John Dickinson
                          Sara Dickinson
                          Allison Mankin
                          Tom Pusateri
	Filename        : draft-bellis-dnsop-session-signal-01.txt
	Pages           : 11
	Date            : 2016-07-21

Abstract:
   The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly
   defined to only have "per-message" semantics.  This document defines
   a new Session Signaling OpCode used to carry persistent "per-session"
   type-length-values (TLVs), and defines an initial set of TLVs used to
   manage session timeouts and termination.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-bellis-dnsop-session-signal-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-bellis-dnsop-session-signal-01
(Continue reading)

Tim Wicinski | 19 Jul 21:45 2016
Picon

Draft Minutes from Monday's meeting


All

here are the draft minutes from Monday's meeting.

https://www.ietf.org/proceedings/96/minutes/minutes-96-dnsop

We want to give a bit shout out to Paul Hoffman for putting these together.

If there are any changes you think need to be made, please let us know.

tim
DNS Operations (DNSOP) Working Group
IETF 96, Berlin
Monday 18 July 2016
Minutes taken Paul Hoffman
Text from slides not included here; please read the slides

Chairs: Tim Wicinski, Suzanne Woolf

Current WG documents: https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html

	Also see https://datatracker.ietf.org/wg/dnsop/documents/


Agenda Bashing, Blue Sheets, etc,
	Nothing

Updates of Old Work
	Three RFCs
(Continue reading)

Paul Wouters | 18 Jul 16:53 2016
Picon
Gravatar

my lone hum against draft-wkumari-dnsop-multiple-responses


The reason I hummed against this idea is that I think it is better to
teach validators to not strip dnssec signed additional data, and just
supply the data there.

The current document as explained today seemed to limit itself already
to in baliwick or subzone data.

That seems a much simpler solution to the proposed problem.

Paul

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

Matthew Pounsett | 18 Jul 16:30 2016

draft-bellis-dnsop-session-signal-00 nit


In § 5.3, the typecode registry leaves codes 3966 and 3967 undefined.


_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-drafts | 18 Jul 15:17 2016
Picon

I-D Action: draft-ietf-dnsop-nxdomain-cut-04.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 of the IETF.

        Title           : NXDOMAIN really means there is nothing underneath
        Authors         : Stephane Bortzmeyer
                          Shumon Huque
	Filename        : draft-ietf-dnsop-nxdomain-cut-04.txt
	Pages           : 11
	Date            : 2016-07-18

Abstract:
   This document states clearly that when a DNS resolver receives a
   response with response code of NXDOMAIN, it means that the domain
   name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   IETF DNSOP (DNS Operations) group, through its mailing list.  The
   source of the document, as well as a list of open issues, is
   currently kept at Github [1].

   This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it
   updates both of them.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-nxdomain-cut-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-nxdomain-cut-04

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

Shane Kerr | 18 Jul 14:13 2016
Gravatar

JavaScript implementation of DNS over HTTP wire format draft

Hello,

tl;dr DNS over HTTP in JavaScript implementation done. Demo here:
      http://blij.tk:8888/

I decided to see how much trouble it would be to use the DNS over HTTP
protocol from JavaScript. I did this over the IETF 96 Hackathon, with
some extra time this morning.

While at first I thought that it made no sense - in fact it seemed
crazy - on reflection there are several good reasons for this.

First, unlike a higher-level API, doing the packet munging yourself
means never having to wait for an API to support the newest, craziest
DNS features.

Second, you have access to the full contents of the DNS packets. That
means getting TTL, seeing full CNAME chains, and so on.

Third, you can do DNSSEC validation if that's what you want.

The demo page explains the details, but I will cover them here for
posterity. (Also I'm not sure how long I will keep the demo up. I have
no plans to turn it off, but it's running on an aging VPS which will
probably need to be revamped at some point.)

----

On the browser side, a JavaScript program builds a DNS wire-format
packet, and then submits it to the server side via a HTTP POST. The
program uses the native-dns-packet JavaScript library combined with the
code using the Browserify tool:

   $ npm install native-dns-packet
   $ npm install buffercursor
   $ browserify test.js -o dnsoverhttpjsdemo.js

The test.js code works with the HTML form and the native-dns-packet
stuff to do the actual work.

On the server side, the DNS over HTTP server proxy written in Go is
run, with a couple of modifications:

* It was modified to act as an HTTP server when
  the /.well-known/dns-wireformat URL is not used.   This allows it to
  serve HTML documents, which is necessary since JavaScript requires
  that all communication is with the same server that the script itself
  comes from. 

* The type specifying the DNS transport requested was changed to
  X-Proxy-DNS-Transport since the browser will not add unknown header
  fields when sending a POST command. 

Source for the server proxy can be found at:

    https://github.com/shane-kerr/DNSoverHTTPinGO/tree/ietf96hackathon. 

It will be merged into the main DNS over HTTP in Go repository soon.

See you at the dnsop session soon! :)

--
Shane
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
internet-drafts | 18 Jul 13:38 2016
Picon

I-D Action: draft-ietf-dnsop-isp-ip6rdns-02.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 of the IETF.

        Title           : Reverse DNS in IPv6 for Internet Service Providers
        Author          : Lee Howard
	Filename        : draft-ietf-dnsop-isp-ip6rdns-02.txt
	Pages           : 13
	Date            : 2016-07-18

Abstract:
   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
   ADDR.ARPA information for their customers by prepopulating the zone
   with one PTR record for every available address.  This practice does
   not scale in IPv6.  This document analyzes different approaches and
   considerations for ISPs in managing the ip6.arpa zone for IPv6
   address space assigned to many customers.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-isp-ip6rdns-02

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

Suzanne Woolf | 16 Jul 13:44 2016
Picon

scribes and notetakers for DNSOP at IETF96

Hi,

This is the usual request for jabber scribes and notetakers for the DNSOP meeting Monday afternoon.

### Date: Monday 18 July 2016
### Time: 15:40-17:40 CEST (13:40-15:40 UTC)
### Room: Bellvue

Please consider volunteering to help out the WG. 

Let the chairs know if you’re willing to do either of these chores— if we have volunteers when we start we
don’t have to spend meeting time negotiating appropriate bribes.

Thanks,
Suzanne & Tim

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
The IESG | 15 Jul 12:01 2016
Picon

Last Call: <draft-ietf-dnsop-nxdomain-cut-03.txt> (NXDOMAIN really means there is nothing underneath) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'NXDOMAIN really means there is nothing underneath'
  <draft-ietf-dnsop-nxdomain-cut-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2016-07-29. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document states clearly that when a DNS resolver receives a
   response with response code of NXDOMAIN, it means that the domain
   name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

   REMOVE BEFORE PUBLICATION: this document should be discussed in the
   IETF DNSOP (DNS Operations) group, through its mailing list.  The
   source of the document, as well as a list of open issues, is
   currently kept at Github [1].

   This documents clarifies RFC 1034 and modifies a bit RFC 2308 so it
   updates both of them.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/ballot/

No IPR declarations have been submitted directly on this I-D.

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


Gmane