Olafur Gudmundsson | 15 Jul 23:18 2014

Re: [Editorial Errata Reported] RFC3757 (4018)

Brian, (guess you are AD responsible) 
IMHO this errata is correct and should be approved. 


On Jun 20, 2014, at 2:56 AM, RFC Errata System <rfc-editor <at> rfc-editor.org> wrote:

> The following errata report has been submitted for RFC3757,
> "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag".
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3757&eid=4018
> --------------------------------------
> Type: Editorial
> Reported by: St├ęphane Bortzmeyer <bortzmeyer <at> nic.fr>
> Section: 1
> Original Text
> -------------
> A SEP key either used to generate a
>   DS RR or is distributed to resolvers that use the key as the root of
>   a trusted subtree
> Corrected Text
> --------------
> A SEP key _is_ either used to generate a
(Continue reading)

RFC Errata System | 20 Jun 09:05 2014

[Errata Held for Document Update] RFC3757 (4018)

The following errata report has been held for document update 
for RFC3757, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag". 

You may review the report below and at:

Status: Held for Document Update
Type: Editorial

Reported by: St?phane Bortzmeyer <bortzmeyer <at> nic.fr>
Date Reported: 2014-06-19
Held by: Ted Lemon (IESG)

Section: 1

Original Text
A SEP key either used to generate a
   DS RR or is distributed to resolvers that use the key as the root of
   a trusted subtree

Corrected Text
A SEP key _is_ either used to generate a
   DS RR or is distributed to resolvers that use the key as the root of
   a trusted subtree

(Continue reading)

Paul Vixie | 31 May 08:08 2014

icann rssac caucus


If you are interested in participating at ICANN's Root Server System Advisory Committee
(https://www.icann.org/resources/pages/charter-2013-07-14-en) as a Caucus member, please kindly
read the relevant information and Caucus document published at
https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en and submit your statement of
interest to rssac-membership <at> icann.org 

The RSSAC executive is working on publishing the final version "Procedures documents" and at the moment is
establishing  the Caucus and with a few work items ready to be discussed by the Caucus.

If you would like to volunteer please kindly indicate those intentions known by sending an email to rssac-membership <at> icann.org.

Kind Regards,

Kaveh Ranjbar, RSSAC Membership Committee Chair
Tripti Sinha, RSSAC Membership Committee Member
Paul Vixie, RSSAC Membership Committee Member

dnsext mailing list
dnsext <at> ietf.org

S Moonesamy | 1 May 17:20 2014

Fwd: Last Call: <draft-moonesamy-sshfp-ed25519-01.txt> (Using ED25519 in SSHFP Resource Records) to Informational RFC


I am forwarding this Last Call announcement (see below) as it is 
something to do with DNS.

S. Moonesamy

>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Using ED25519 in SSHFP Resource Records'
>   <draft-moonesamy-sshfp-ed25519-01.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-05-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.
>    The Ed25519 signature algorithm has been implemented in OpenSSH.
>    This document updates the IANA "SSHFP RR Types for public key
>    algorithms" registry by adding an algorithm number for Ed25519.
>The file can be obtained via
(Continue reading)

Mark Andrews | 19 Mar 17:19 2014

BADVERS returned for unknown EDNS option

	Is the vendor of the nameservers cpb.gov are runnning willing
	to standup and issue a recall notice for the version they
	are running.  version.bind returns "3.2.2" 

	When presented a unknown EDNS option they return BADVERS
	rather then ignoring the option.  The EDNS RFCs (both the
	original and the replacement) are explict about what
	conditions set BADVERS.

	This sort of mis-behaviour make it very difficult to deploy
	new EDNS options.


; <<>> DiG 9.10.0b2 <<>>  <at> sauthns1.qwest.net cpb.gov +nsid
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39491
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags:; udp: 4096
;cpb.gov.			IN	A

;; Query time: 12 msec
;; SERVER: 2001:428::7#53(2001:428::7)
(Continue reading)

Hosnieh Rafiee | 4 Mar 15:29 2014

Please submit your questions about cga-tsig to mailing list

Just a two remarks or highlights about the presentation:
-  Data confidentiality can also be used in the resolver scenario the same
way as zone transfer scenario that is explained during presentation as an
example scenario. 
- The proof of concept or implementation in NL Net labs is only available
for resolver scenario as I also explained in my previous messages to the
mailing list everytime I discussed about the implementation
But the early versions of this draft was implemented for powerDNS (as a
proof of concepts)
- This draft does not only works in cases where SeND is available but as
also Erik mentioned, it works when you generate your CGA address and assign
it like a static address.

Thank you,

dnsext mailing list
dnsext <at> ietf.org

Hosnieh Rafiee | 28 Feb 15:55 2014

We want to have fruitful discussions - please review

Dear All,

Since we have a timeslot to present
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig in DNSOP. I ask you
please review it so that the discussion would be fruitful and we can receive
good comments to improve it and to move ahead.  This draft is not a new one
as many of you already know or heard about it, it was first presented in
IETF 85 and recently in IETF 88 in Int-area. The reason was because it was
more related to DNSEXT and at that time it was going to shut down. It had
several volunteer reviewers and it received some good comments. However, we
would like to receive more comments in case we missed anything that needs to
be addressed or we missed to clarify any section in the draft that needs
more clarifications. Since now the DNS confidentiality is also an important
topic and this proposal could handle it for IPv6 and during data transfer, I
also included a section and explained the required changes to the original

Here again I briefly explain the purpose of this document for those who do
not know about it or who do not know the exact purpose of it:

This proposal is for the cases where DNS uses IPv6 and there is a need to
use a security mechanism for DNS authentication or provide the data
confidentiality for the DNS data during transferring data over the network.
It is possible to use this proposal in different DNS scenarios such as DNS
update, updating FQDN and PTR, or DNS resolving. In this case it is enough
that the verifier node only knows the IP address of the DNS server or
resolver. For DNS update, this IP address can be set manually for the first
time in the DNS configuration file and for other times, the CGA-TSIG can
handle the changes with the proposed specifications. For DNS resolver, it
receives this IP address securely via the option in the router advertisement
(Continue reading)

Andrew Sullivan | 25 Jan 03:12 2014

[brian <at> innovationslab.net: [dns-dir] Heads up on a London BoF]

Dear colleagues,

Please see Brian's note below.  It will be important to get people
with protocol expertise into this room.


----- Forwarded message from Brian Haberman <brian <at> innovationslab.net> -----

Date: Fri, 24 Jan 2014 08:31:19 -0500
From: Brian Haberman <brian <at> innovationslab.net>
To: IETF DNS Directorate <dns-dir <at> ietf.org>
Subject: [dns-dir] Heads up on a London BoF
List-Id: IETF DNS directorate discussion list <dns-dir.ietf.org>

    I have agreed to sponsor a BoF in London to look into adding
confidentiality to DNS.  The current description of the DNSE BoF is
available at:


I want to encourage the DNS protocol experts to participate in the BoF.
 The primary focus will be on discussing whether there are existing ways
to accomplish the goals described in the problem statement draft
targeted for the DNSOP WG.

If you have any questions, feel free to let me know.

(Continue reading)

Marc Buijsman | 16 Jan 15:45 2014

CGA-TSIG research report

Dear working group members,

For my master's thesis I have performed an investigation at NLnet Labs 
on CGA-TSIG as a solution to the last mile problem of DNS. The version 
of the CGA-TSIG proposal that I reviewed is the current latest version 
at http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06. During 
the course of my research I have already had some contact with Ms. Rafiee.

In order to do a verification of the CGA-TSIG proposal I have created a 
proof of concept implementation in NLnet Labs' "ldns" library. Since the 
scope of the project was limited to the last mile problem it only 
includes the code required for this purpose, but the implementation 
could easily be extended to support other applications (like zone 
transfers). I have found that CGA-TSIG has potential to be an adequate 
solution to the last mile problem on IPv6 networks, although some future 
research is needed with regard to bootstrapping the authentication.

As a result, I would hereby like to refer you to my report which can be 
found at 
I have outlined my results in section 4.2 which contains suggestions on 
how I believe the CGA-TSIG draft could be clarified and otherwise 
improved. I hope my suggestions will be adopted in the next version of 
the draft. The PoC code can be found in the online Git repository of 
NLnet Labs at http://git.nlnetlabs.nl/ldns/?h=cga-tsig.

I hope my work will be helpful in standardising CGA-TSIG.

Yours sincerely,

(Continue reading)

Sourav Sain | 14 Jan 16:55 2014

Order of a record and its RRSIG in response



RFC 4035, section 3.1.1, mentions when a security-aware authoritative Name Server should include RRSIG records in response while placing a signed RRSET in a section in response.


Is there any clarification on the order in which a signed record and its associated RRSIG are to be included in a section. For example when including an A record and its RRSIG, is it that the name Server will always place the A record first followed by its RRSIG in response or can it be RRSIG of A record followed by the A record as well?


Going further, if, for example, a query comes for a.example.com type ALL and there are A and AAAA records for a.example.com in the zone, is there an expected order in which the authoritative name server will include the 4 records (A, RRSIG(A), AAAA, RRSIG(AAAA)) in response’s answer section? Is there any guidance around this.



Sourav Sain


dnsext mailing list
dnsext <at> ietf.org
Tony Finch | 18 Dec 13:18 2013

Support for 1RTT multi-queries over TCP (or lack thereof)

I saw a message to the unbound-users list which says unbound processes TCP
queries sequentially.


I thought this was disappointingly poor, especially wrt the recent
discussion about backwards-compatible alternatives to edns-chain-query. So
I did a quick test to see if BIND has the same problem. I shoved a few
entries from the Alexa Top 1 Million list into adns as follows.

$ sed 's|^[0-9]*,||;s|/.*||' top-1m.csv | head -100 |
  adnshost --cname-loose --asynch --pipe

Over UDP you can clearly see the response serial numbers are out-of-order,
and the whole thing runs in about 3 seconds with a cold cache.

If I add --tcp to the adnshost command line the responses come back
strictly in order and BIND processes them one at a time. Processing all
the queries takes more than 30 seconds, so adns times out before getting
responses to the last 25 queries. (When you invoke adnshost like this it
does not by itself do anything to limit the number of outstanding
queries.) In addition to that, named fails to notice that the TCP socket
has gone away and continues to process queries. (I will report this as a

So that is doubly disappointing.


f.anthony.n.finch  <dot <at> dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
dnsext mailing list
dnsext <at> ietf.org