Ray Bellis | 23 Feb 14:18 2016
Picon

Re: [dns-rrtype-applications] "AVC" RRTYPE PARAMETER ALLOCATION (was "DNSAS")


On 14/02/2016 09:05, Wolfgang Riedel (wriedel) wrote:
> Hello,
> 
> as requested attached our re-worked request for an assignment for a
> new DNS Resource Record for mnemonic=AVC. Please let me know if there
> is anything unclear or missing and what the next steps would be.

Having received no further comments, as the Designated Expert according
to RFC 6895 I hereby approve the application for the "AVC" RRTYPE as
described in the attached template.

Ray Bellis
                 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE

   When ready for formal consideration, this template is to be submitted
   to IANA for processing by emailing the template to dns-rrtype-applications <at> ietf.org.

   A. Submission Date:

   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: Wolfgang Riedel       Email Address: wolfgang <at> cisco.com
      International telephone number: +49-811-559-5450
      Other contact handles: 

(Continue reading)

RFC Errata System | 19 Feb 17:48 2016

[Errata Verified] RFC5155 (4622)

The following errata report has been verified for RFC5155,
"DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=4622

--------------------------------------
Status: Verified
Type: Technical

Reported by: Robert Edmonds <edmonds <at> mycre.ws>
Date Reported: 2016-02-18
Verified by: Brian Haberman (IESG)

Section: 7.2.8

Original Text
-------------
7.2.8.  Responding to Queries for NSEC3 Owner Names

   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
   chain like other owner names.  As a result, each NSEC3 owner name is
   covered by another NSEC3 RR, effectively negating the existence of
   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
   can be proven by its RRSIG RRSet.

   If the following conditions are all true:

   o  the QNAME equals the owner name of an existing NSEC3 RR, and
(Continue reading)

Ray Bellis | 18 Feb 18:46 2016
Picon

Fwd: [dns-rrtype-applications] DNS-AS RRTYPE PARAMETER ALLOCATION

Wolfgang Riedel has submitted an updated application (attached),
addressing my previous comments by replacing the mnemonic with "AVC",
and also now explicitly documenting that the RDATA format is identical
to a "TXT" record.

I see no reason to reject this application, and intend to approve it on
Monday unless there's any vigorous objections.

Ray Bellis

-------- Forwarded Message --------
Subject: 	[dns-rrtype-applications] dns-rrtype-applications] DNS-AS
RRTYPE PARAMETER ALLOCATION
Date: 	Sun, 14 Feb 2016 09:05:14 +0000
From: 	Wolfgang Riedel (wriedel) <wriedel <at> cisco.com>
To: 	iana-prot-param <at> iana.org <iana-prot-param <at> iana.org>,
dns-rrtype-applications <at> ietf.org <dns-rrtype-applications <at> ietf.org>

Hello,

as requested attached our re-worked request for an assignment for a new
DNS Resource Record for mnemonic=AVC.
Please let me know if there is anything unclear or missing and what the
next steps would be.

                 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE

   When ready for formal consideration, this template is to be submitted
(Continue reading)

RFC Errata System | 18 Feb 02:36 2016

[Technical Errata Reported] RFC5155 (4622)

The following errata report has been submitted for RFC5155,
"DNS Security (DNSSEC) Hashed Authenticated Denial of Existence".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=4622

--------------------------------------
Type: Technical
Reported by: Robert Edmonds <edmonds <at> mycre.ws>

Section: 7.2.8

Original Text
-------------
7.2.8.  Responding to Queries for NSEC3 Owner Names

   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
   chain like other owner names.  As a result, each NSEC3 owner name is
   covered by another NSEC3 RR, effectively negating the existence of
   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
   can be proven by its RRSIG RRSet.

   If the following conditions are all true:

   o  the QNAME equals the owner name of an existing NSEC3 RR, and

   o  no RR types exist at the QNAME, nor at any descendant of QNAME,

   then the response MUST be constructed as a Name Error response
(Continue reading)

John R Levine | 13 Feb 22:48 2016

Any interest in draft-latour-dnsoperator-to-rrr-protocol ?

I noticed the -02 of this draft go by yesterday.

It's a very rough version of a DNSSEC key record bootstrap design in which 
the operator of the delegated zone pokes the operator of the upper level 
zone using http, which tells the upper level zone to import keys from the 
delegated zone's CDS and CDNSKEY records.

Is there much interest in this?

On my tiny DNS server I have over 100 signed zones where I can't install 
the upper level DS records because I'm not the registrant, I'm just 
running their DNS.  It would be nice to have a way to do that that scales 
better than walking each of the registrants through their registrars' 
DNSSEC update processes.

R's,
John

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

Ray Bellis | 10 Feb 13:26 2016
Picon

Re: DNS-AS RRTYPE PARAMETER ALLOCATION

Wolfgang,

I've been appointed as the designated expert to review your RRTYPE
application per RFC 6895.

In principle the application is OK, and it's highly desirable that you
avoid use of TXT.

Within my remit however I do have some concerns over the name of the RRTYPE:

- the term "authoritative" has a particular meaning in the DNS
  protocol, and "authoritative source" is a commonly used term
  too.  Typing "dns authoritative source" into Google already
  produces 75,000 results, none that I could see relating to
  your project.

- using "DNS" within the RRTYPE name seems redundant - we're
  already in the DNS.

- the letters "AS" are also commonly used to refer to a BGP
  "Autonomous System".

[FWIW, when I first saw your requested mnemonic in the subject of your
application I was expecting to see an application for an RRTYPE to
represent a BGP AS number!]

Also missing is any explicit statement that the intended wire and
presentation format are identical to that of a TXT record.
Consideration should also be given to what happens if the data does not
fit within a single 255 octet "character-string" sub-field.
(Continue reading)

RFC Errata System | 14 Dec 16:08 2015

[Errata Verified] RFC4034 (4552)

The following errata report has been verified for RFC4034,
"Resource Records for the DNS Security Extensions". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=4552

--------------------------------------
Status: Verified
Type: Technical

Reported by: Ben Laurie <benl <at> google.com>
Date Reported: 2015-12-04
Verified by: Brian Haberman (IESG)

Section: Appendix B

Original Text
-------------
These groups are then added together, ignoring any carry bits.

Corrected Text
--------------
These groups are then added together with at least 32-bit precision,
retaining any carry bits.
The carry bits are then added to the result, and finally, only the lower
16 bits of the result are used as the key tag. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.
(Continue reading)

RFC Errata System | 4 Dec 13:01 2015

[Technical Errata Reported] RFC4034 (4552)

The following errata report has been submitted for RFC4034,
"Resource Records for the DNS Security Extensions".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=4552

--------------------------------------
Type: Technical
Reported by: Ben Laurie <benl <at> google.com>

Section: Appendix B

Original Text
-------------
These groups are then added together, ignoring any carry bits.

Corrected Text
--------------
These groups are then added together with at least 32-bit precision,
retaining any carry bits.
The carry bits are then added to the result, and finally, only the lower
16 bits of the result are used as the key tag. Note that this means any
carries generated during the addition of the carry bits are ignored.
This, in turn, means that the keytag calculation is often the same as
reduction modulo 65535, but not always.

Notes
-----
Errata 2681 already proposes a fix to Appendix B, however the proposed fix is not quite clear. The first part
(Continue reading)

RFC Errata System | 9 Nov 17:12 2015

[Errata Held for Document Update] RFC4635 (4526)

The following errata report has been held for document update 
for RFC4635, "HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm
Identifiers". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4635&eid=4526

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Richard Hansen <rhansen <at> bbn.com>
Date Reported: 2015-11-09
Held by: Brian Haberman (IESG)

Section: 2

Original Text
-------------
      Optional       hamc-sha384

Corrected Text
--------------
      Optional       hmac-sha384

Notes
-----
Simple typo (transposed characters).

(Continue reading)

RFC Errata System | 9 Nov 10:00 2015

[Editorial Errata Reported] RFC4635 (4526)

The following errata report has been submitted for RFC4635,
"HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4635&eid=4526

--------------------------------------
Type: Editorial
Reported by: Richard Hansen <rhansen <at> bbn.com>

Section: 2

Original Text
-------------
      Optional       hamc-sha384

Corrected Text
--------------
      Optional       hmac-sha384

Notes
-----
Simple typo (transposed characters).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
(Continue reading)

RFC Errata System | 14 Oct 15:33 2015

[Errata Verified] RFC3110 (4502)

The following errata report has been verified for RFC3110,
"RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3110&eid=4502

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Mikko Rantanen <rfc-dog <at> hole.fi>
Date Reported: 2015-10-14
Verified by: Brian Haberman (IESG)

Section: 4

Original Text
-------------
conservative choice would be 65537 (F4, the fourth fermat number).

Corrected Text
--------------
conservative choice would be 65537 (F4, the fifth Fermat number).

Notes
-----
Numbering of Fermat numbers starts from zero. F4 and 65537 agree, but F4 is fifth Fermat number in the
series, not fourth.

(Continue reading)


Gmane