Frederico A C Neves | 23 Jul 23:34 2014

OPENPGPKEY RRTYPE review - Comments period ends Aug 6th

Dear Colleagues,

Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC6895.

This message starts a 2 weeks period for an expert review of the DNS
RRTYPE parameter allocation for OPENPGPKEY specified at:

If you have comments regarding this request please post them here
before Aug 6th 21:00 UTC.

Best Regards,
Frederico Neves

--begin 6895 template TLSA--
 A. Submission Date: 23-07-2014

 B.1 Submission Type:  [x] New RRTYPE  [ ] Modification to RRTYPE
 B.2 Kind of RR:  [x] Data RR  [ ] Meta-RR

 C. Contact Information for submitter (will be publicly posted):
    Name: Paul Wouters         Email Address: pwouters <at>
    International telephone number: +1-647-896-3464
    Other contact handles: paul <at>

 D. Motivation for the new RRTYPE application.

    Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC
(Continue reading)

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>> 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:
> --------------------------------------
> Type: Editorial
> Reported by: St├ęphane Bortzmeyer <bortzmeyer <at>>
> 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>>
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
( as a Caucus member, please kindly
read the relevant information and Caucus document published at and submit your statement of
interest to rssac-membership <at> 

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>

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>

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> mailing lists by 2014-05-29. Exceptionally, comments may be
>sent to iesg <at> 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 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> +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
;			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>

Hosnieh Rafiee | 28 Feb 15:55 2014

We want to have fruitful discussions - please review

Dear All,

Since we have a timeslot to present 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> [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>> -----

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

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

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 type ALL and there are A and AAAA records for 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>