Hosnieh Rafiee | 25 Aug 11:16 2014

FW: New Version Notification for draft-rafiee-intarea-cga-tsig-10.txt


Since I received comments that still the problem explained in the draft is not so clear. I re-organized it
and focused on problem statement. If I compared this draft with other approaches is only to give you an idea
that how it can protect the last mile of Internet where DNSSEC or other approaches cannot do it easily
especially for IPv6. 
Since I am not longer convinced about DNS confidentiality unless the surveillance actor has no access to
other flows without sniffing DNS flows (or he needs to use DNS flows as a helper to do this sniffing), I put
encryption as an optional cases that this draft can support. 

So the main focus is authentication of scenarios where at the moment not supported by other mechanisms. 

I welcome any comments or suggestions.

A new version of I-D, draft-rafiee-intarea-cga-tsig-10.txt
has been successfully submitted by Hosnieh Rafiee and posted to the IETF repository.

Name:		draft-rafiee-intarea-cga-tsig
Revision:	10
Title:		CGA-TSIG/e: Algorithms for Secure DNS Authentication and Optional DNS Confidentiality
Document date:	2014-08-25
Group:		Individual Submission
Pages:		37
URL:            http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-10.txt
Status:         https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/
Htmlized:       http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-10
Diff:           http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-10
(Continue reading)

Paul Hoffman | 20 Aug 19:22 2014

New draft on representing DNS messages in JSON

Greetings again. I have a need for expressing DNS messages in JSON for an application I have written.
Stephane and I had started to work on this but ended up dropping it.
draft-dulaunoy-kaplan-passive-dns-cof comes at the same problem from another direction, but it is
specific for one problem space and isn't using real JSON.

So, I whipped this one up. I intend it to be Experimental because I have no idea if anyone other than me wants
it. Also, I don't think it should be a WG document if only a few folks have need for the format. However, I
would love to heard comments and suggestions.

--Paul Hoffman

A new version of I-D, draft-hoffman-dns-in-json-00.txt
has been successfully submitted by Paul Hoffman and posted to the
IETF repository.

Name:		draft-hoffman-dns-in-json
Revision:	00
Title:		Representing DNS Messages in JSON
Document date:	2014-08-20
Group:		Individual Submission
Pages:		10
URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-in-json-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/
Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-in-json-00

  Some applications use DNS messages, or parts of DNS messages, as
  data.  For example, a system that captures DNS queries and responses
  might want to be able to easily search those without having to decode
  the messages each time.  Another example is a system that puts
(Continue reading)

Mark Andrews | 14 Aug 02:16 2014

Re: draft-ietf-dnsop-rfc6598-rfc6303-01

	Can we please move on this.

	The reverse address are not yet insecurely delegated as
	would be required for RFC 6598 compliance.  This is starting
	to cause operational problems for ISP's that validate DNS
	responses as they can't deploy local IN-ADDR.ARPA zones
	until that insecure delegation is done.

	Also should I add a reminder to the IANA Considerations that
	the insecure delegation needs to be performed?


	"IANA is reminded that a insecure delegation for these zones
	is required for compliance with RFC 6598 to break the DNSSEC
	chain of trust."


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

DNSOP mailing list
DNSOP <at> ietf.org

(Continue reading)

The IESG | 8 Aug 17:16 2014

Last Call: <draft-ietf-dnsop-child-syncronization-02.txt> (Child To Parent Synchronization in DNS) to Proposed Standard

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Child To Parent Synchronization in DNS'
  <draft-ietf-dnsop-child-syncronization-02.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 2014-08-22. 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.


   This document specifies how a child zone in the DNS can publish a
   record to indicate to a parental agent that it may copy and process
   certain records from the child zone.  The existence of and value
   change of the record may be monitored by a parental agent and acted
   on as appropriate.

The file can be obtained via

IESG discussion can be tracked via

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

DNSOP mailing list
(Continue reading)

Toerless Eckert | 6 Aug 13:47 2014

Anycast and DNS questions

Sorry, haven't been following this group for a long time, so
please excuse if answers to these questions have been discussed in before:

a) What documents beside RFC3258  are describing any uses/procedures
   for having DNS servers use an anycast address to receive and respond to
   requests ?

b) How common are deployments in which the information returned by different
   anycast member DNS servers for the same query would be different,
   aka: to "localize" lookup results, such as pointing to
   local CDN caches or the like ? What would be the most well known examples
   of such deployed instances ?  Any IETF documents describing this ? Any
   rules to follow ?

c) Any example in which the DNS servers utilizing a single shared
   IP address (anycast address) are run by different operators ? Any
   documents describing this ? (RFC3258 seems to focus on single operator
   anycast group of DNS servers.


DNSOP mailing list
DNSOP <at> ietf.org

internet-drafts | 31 Jul 22:11 2014

I-D Action: draft-ietf-dnsop-rfc6304bis-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           : AS112 Nameserver Operations
        Authors         : Joe Abley
                          William F. Maton
	Filename        : draft-ietf-dnsop-rfc6304bis-04.txt
	Pages           : 30
	Date            : 2014-07-31

   Many sites connected to the Internet make use of IPv4 addresses that
   are not globally-unique.  Examples are the addresses designated in
   RFC 1918 for private use within individual sites.

   Devices in such environments may occasionally originate Domain Name
   System (DNS) queries (so-called "reverse lookups") corresponding to
   those private-use addresses.  Since the addresses concerned have only
   local significance, it is good practice for site administrators to
   ensure that such queries are answered locally.  However, it is not
   uncommon for such queries to follow the normal delegation path in the
   public DNS instead of being answered within the site.

   It is not possible for public DNS servers to give useful answers to
   such queries.  In addition, due to the wide deployment of private-use
   addresses and the continuing growth of the Internet, the volume of
   such queries is large and growing.  The AS112 project aims to provide
   a distributed sink for such queries in order to reduce the load on
   the corresponding authoritative servers.  The AS112 project is named
(Continue reading)

Mark Andrews | 31 Jul 06:14 2014

DNS URI code point wire format

	When DNS code points are issued based on the request template
	the wire and presentation values are supposed to be fixed.

	URI was issued against draft-faltstrom-uri-05/06.  The wire
	format has been changed in draft-faltstrom-uri-08 in
	particular how the target field is encoded.

	named implemented URI as per draft-faltstrom-uri-05/06
	unbound implemented URI as per draft-faltstrom-uri-08

	We now have two incompatible implementations in the wild.

	We are going to change named to implement draft-faltstrom-uri-08.
	The changes were just committed and will be available in
	the upcoming maintainence releases.

	I would suggest that IANA update or otherwise make a note
	that the wire encoding is that from draft-faltstrom-uri-08
	or else there will be future incompatibilities.


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

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

Fernando Gont | 28 Jul 14:24 2014

DNS, fragmentation, and IPv6 extension headers


(Apologies if this has been debated to death already).

At the last IEPG meeting we presented some results regarding the
filtering of packets that employ IPv6 extension headers (please see:
The packet drop rates range from 10% to over 50%, depending on the
dataset (FWIW, these packets drops have nothing to do with DNS-specific
packet-drops caused by sloppy firewalls or the like).

This essentially raises the question of "What's the plan for
transporting DNS queries/responses in IPv6?"

At different venues (including the IETF), I've received/listened_to
different opinions. Quite a few folks usually argue "oh, that's simple:
we'll use TCP", while others tend to argue that "one should be careful
when thinking about relying on TCP for DNS queries/responses" (e.g. see

While this issue/question may be currently masqueraded by the fact that
we still have IPv4, I wonder what's "the plan" for the IPv6 case (at
some point, we'll have to rely on whatever such plan is).

If the answer is "fall-back to TCP if UDP doesn't work", my next
question would be "does popular DNS server software implement
mitigations for TCP-based attacks?" (zero-windows, FIN-WAIT-X flooding,

(Continue reading)

Edward Lewis | 27 Jul 00:53 2014

Re: Changing NSEC3 salts regularly is useless

There’s a lot of guidance needed for operators and tools developers (who set defaults) with regards to
DNSSEC.  (I.e., Define and quantify “useless.”)

Three old presentations on studies (involving operations TLDs only) I have done on this topic in 2012:

(how the protocol engineer’s expectations differed from what operators were doing)

(began to analyze the difference between protocol engineering and operations)

(same, based on more data)

If you are going to produce such a document, cover a range of choices being made, including the salt change
frequency.  There’s been a strong need for a DNSSEC implementers guide covering cryptographic
parameter selection ever since well, forever.  Yes we have NIST 800-81 (http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf).

One issue with the salt (in particular) is that the RFC recommendation is (RFC 5155  Appendix C.1) says this:

"The salt SHOULD be changed periodically to prevent pre-computation using a single salt.  It is
RECOMMENDED that the salt be changed for every re-signing."

This was written without dynamically updated zones in mind (or so I’m guessing - 5155 is “not my
fault” ;) ).

On Jul 24, 2014, at 18:02, Mark Andrews <marka <at> isc.org> wrote:

> I just sent the following to bind-users.  We need to kill the myth
(Continue reading)

Mark Andrews | 25 Jul 00:02 2014

Changing NSEC3 salts regularly is useless

I just sent the following to bind-users.  We need to kill the myth
that changing NSEC3 salt provides any real benefit.

"Actually it is useless to change the salt regularly.  Changing the
salt provides no real benefit against discovering the names in a
zone which is the reason people were saying to change the salt.

The attacker uses cached NSEC3 records.  When it gets a cache miss
it asks the servers for the zone, puts the answer in the cache and
continues.  When the salt changes it just maintains multiple nsec3
chains eventually discarding the old nsec3 chain eventually.  I
would wait until the new NSEC3 chain has as many cached records as
the old NSEC3 chain.  Changing the salt slows things up miniminally
for a very short period of time after the change.  Additionally
once you have some names you ask for those names for a non-exisisting
type to quickly pull in part of the new NSEC3 chain you know exists.

The only reason to change the salt is if you have a collision of
the hashed names.  This will be a very very very rare event."


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka <at> isc.org

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

David Conrad | 22 Jul 16:22 2014

Masataka Ohta's 2004 draft...

Since I mentioned it and some folks said "where is it?":



DNSOP mailing list
DNSOP <at> ietf.org