Paul Hoffman | 28 Nov 16:28 2014

Fwd: New Version Notification for draft-hoffman-dns-terminology-00.txt

Greetings. Andrew and Kazunori and I have prepared the first draft of what will hopefully be a useful
document collecting definitions that useful in the DNS community. We fully admit that this is quite
rough, and didn't even try to do definitions for some of the terms that we expect to be filled in before we are done.

The idea is that this will be an IETF consensus document, if possible, but we are not yet asking for adoption
in the DNSOP WG, and we might not even later. For now, we'd like to hear what additional terms should be
added, what clarifications to the terms we already have would be helpful, and so on.

--Paul Hoffman

> A new version of I-D, draft-hoffman-dns-terminology-00.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-hoffman-dns-terminology
> Revision:	00
> Title:		DNS Terminology
> Document date:	2014-11-28
> Group:		Individual Submission
> Pages:		9
> URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/
> Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-terminology-00
> 
> 
> Abstract:
>   The DNS is defined in literally dozens of different RFCs.  The
>   terminology used in by implementers and developers of DNS protocols,
>   and by operators of DNS systems, has sometimes changed in the decades
>   since the DNS was first defined.  This document gives current
(Continue reading)

Wes Hardaker | 27 Nov 01:55 2014
Picon
Picon

IESG COMMENT/DISCUSSION responses to the dnsop-child-sync draft


After *way* too long of a delay (entirely my fault), here are some
responses to the IESG about the comments and discusses on the document.
It's close to finalized I hope, and I did publish a -04 to reflect the
changes made below.  Below is a list of the IESG member's and their
comments, as well as responses to them from me (starting with a marking
of "WJH:").

Notes from IESG review (of -03):

* DONE Alia Atlas

*** DONE First sentence in Sec 1 is missing an it:
    :LOGBOOK:
    - State "DONE"       from "TODO"       [2014-11-25 Tue 16:05]
    :END:
    "This document specifies how a child zone in the DNS ([RFC1034],
       [RFC1035]) can publish a record to indicate to a parental agent that
       can copy and process certain records from the child zone."

    WJH: Added

*** DUP In Sec 2: What does unpunishable data mean in
    :LOGBOOK:
    - State "DONE"       from "TODO"       [2014-11-25 Tue 16:06]
    :END:
    "Errors due to unsupported Type Bit Map bits, or otherwise
    nonpunishable data, SHALL result in no change to the parent zone's
    delegation information for the Child."

(Continue reading)

internet-drafts | 27 Nov 01:52 2014
Picon

I-D Action: draft-ietf-dnsop-child-syncronization-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 Working Group of the IETF.

        Title           : Child To Parent Synchronization in DNS
        Author          : Wes Hardaker
	Filename        : draft-ietf-dnsop-child-syncronization-04.txt
	Pages           : 14
	Date            : 2014-11-26

Abstract:
   This document specifies how a child zone in the DNS can publish a
   record to indicate to a parental agent that the parental agent may
   copy and process certain records from the child zone.  The existence
   of the record and any change in its value can be monitored by a
   parental agent and acted on depending on local policy.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-child-syncronization-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-child-syncronization-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:
(Continue reading)

Paul Hoffman | 26 Nov 21:42 2014

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

Greetings. Warren and I updated the draft a bit to reflect input from the WG, and to add another
configuration example (for Windows Server).

--Paul Hoffman

> Begin forwarded message:
> 
> From: internet-drafts <at> ietf.org
> To: "Warren Kumari" <warren <at> kumari.net>, "Paul E. Hoffman" <paul.hoffman <at> vpnc.org>, Warren Kumari
<warren <at> kumari.net>, Paul Hoffman <paul.hoffman <at> vpnc.org>
> Subject: New Version Notification for draft-wkumari-dnsop-root-loopback-02.txt
> Date: November 26, 2014 at 12:39:34 PM PST
> 
> 
> A new version of I-D, draft-wkumari-dnsop-root-loopback-02.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Name:		draft-wkumari-dnsop-root-loopback
> Revision:	02
> Title:		Decreasing Access Time to Root Servers by Running One on Loopback
> Document date:	2014-11-26
> Group:		Individual Submission
> Pages:		9
> URL:            http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-root-loopback-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-wkumari-dnsop-root-loopback/
> Htmlized:       http://tools.ietf.org/html/draft-wkumari-dnsop-root-loopback-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-root-loopback-02

_______________________________________________
(Continue reading)

Tim Wicinski | 26 Nov 16:58 2014
Picon

Call for Adoption draft-livingood-dnsop-negative-trust-anchors


This starts a Call for Adoption for 
draft-livingood-dnsop-negative-trust-anchors. There was much discussion 
at the last meeting about adopting this draft and working on it.

The draft is available here:
	https://datatracker.ietf.org/doc/draft-livingood-dnsop-negative-trust-anchors/

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 Wednesday, December 10th, 2014

Thanks,
tim wicinski
DNSOP co-chair

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

Dave Thaler | 26 Nov 16:37 2014
Picon

Comment on draft-ietf-dnsop-as112-dname-06.txt

[note: I am not on the dnsop mailing list, so keep me on any replies]

One issue I have is with the first paragraph of the Introduction:

> Many sites connected to the Internet make use of IPv4 addresses that 
> are not globally unique.  Examples are the addresses designated in 
> [RFC1918] for private use within individual sites.

This makes it sound like the only use cases are for IPv4 addresses, which is not correct.  The DNS is also used
at times for multicast addresses, including locally scoped ones, and such "private use" multicast
addresses occur both in IPv4 and IPv6.

I have no data on whether anyone is _currently_ using AS112 for such, but
the point is that potential applicability is not limited to IPv4 as implied.

-Dave

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

IETF Secretariat | 24 Nov 17:19 2014
Picon

ID Tracker State Update Notice: <draft-ietf-dnsop-dnssec-key-timing-06.txt>

Last call has been made for draft-ietf-dnsop-dnssec-key-timing and state has been changed to In Last Call
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

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

internet-drafts | 24 Nov 17:21 2014
Picon

I-D Action: draft-ietf-dnsop-as112-dname-06.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           : AS112 Redirection using DNAME
        Authors         : Joe Abley
                          Brian Dickson
                          Warren Kumari
                          George Michaelson
	Filename        : draft-ietf-dnsop-as112-dname-06.txt
	Pages           : 16
	Date            : 2014-11-24

Abstract:
   AS112 provides a mechanism for handling reverse lookups on IP
   addresses that are not unique (e.g., RFC 1918 addresses).  This
   document describes modifications to the deployment and use of AS112
   infrastructure that will allow zones to be added and dropped much
   more easily, using DNAME resource records.

   This approach makes it possible for any DNS zone administrator to
   sink traffic relating to parts of the global DNS namespace under
   their control to the AS112 infrastructure without coordination with
   the operators of AS112 infrastructure.

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-06
(Continue reading)

The IESG | 24 Nov 17:19 2014
Picon

Last Call: <draft-ietf-dnsop-dnssec-key-timing-06.txt> (DNSSEC Key Rollover Timing Considerations) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNSSEC Key Rollover Timing Considerations'
  <draft-ietf-dnsop-dnssec-key-timing-06.txt> as Informational RFC

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 2014-12-08. 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 describes the issues surrounding the timing of events
   in the rolling of a key in a DNSSEC-secured zone.  It presents
   timelines for the key rollover and explicitly identifies the
   relationships between the various parameters affecting the process.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/ballot/

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

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
(Continue reading)

IETF Secretariat | 24 Nov 07:37 2014
Picon

ID Tracker State Update Notice: <draft-ietf-dnsop-dnssec-key-timing-06.txt>

IESG state changed to Last Call Requested from AD Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/

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

Michael Richardson | 23 Nov 22:14 2014
X-Face
Picon

ip6.arpa reverse delegation


I have read:
  Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation
  draft-andrews-dnsop-pd-reverse-02

as a method to delegate reverse zones to CPE devices as the prefix
is delegated.  I find the method entirely sensible, and I think highly
secure.  I don't know if this belongs in dnsop or in homenet (or dhcpv6,
since a new DHCPv6 option is requested, and this enhances DHCPv6-PD): I'll
let the INT and Ops ADs sort that out.

I suggest that one of these WGs should adopt it, and even suggest that this
document should Updates: 6204/7084.  If I had the required code point, I
would implement it today in an IPv6 ACS I work on (ServPOET), and contribute
code to Barrier Breaker OpenWRT (to dnsmasq) to do the client end.

I want to say that this is very similar to the way that the "wavesec"
mechanism that the FreeS/WAN project experimented with a decade ago (a few
Minneapolis and Atlanta IETF networks back around IETF50).  We used DHCP
to carry a key, this was installed by TSIG update by the DHCP(v4) server, and
was used to populate the reverse DNS.  The result was an IPsec
laptop/32<->gateway(0.0.0.0/0) tunnel, using IPsec for security across the
wireless rather than the WEP that was common at the time.

--

-- 
Michael Richardson <mcr+IETF <at> sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

(Continue reading)


Gmane