Subject: Re: [dnsext] Trustworthiness of DNSSEC data

From: =JeffH <[email-masked]>
Date: Sun, 26 Jun 2011 17:14:52 -0700

> More generally, DNSSEC holds
 > enormous potential utility as a repository of integrity-protected
 > authoritative information about DNS names, including configuration for
 > new opt-in security schemes.  However, each of these schemes may
 > increase the degree of exposure to malfeasance by the DNS operator (who
 > may not be the same entity as the authoritative holder of the domain) in
 > some or all cases, compared to traditional practice.

Not to say that having these concerns is misplaced, but the DNSop WG, as well 
as various DNS operators, have been thinking along these lines...

http://tools.ietf.org/wg/dnsop/

"DPS" = DNSSEC Practice Statement

..perhaps further discussion should go to the [email-masked] list?

There's also: [email-masked]

HTH,

=JeffH

---

DNSSEC Operational Practices, Version 2
http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis

Abstract

    This document describes a set of practices for operating the DNS with
    security extensions (DNSSEC).  The target audience is zone
    administrators deploying DNSSEC.

    The document discusses operational aspects of using keys and
    signatures in the DNS.  It discusses issues of key generation, key
    storage, signature generation, key rollover, and related policies.

    This document obsoletes RFC 4641 as it covers more operational ground
    and gives more up-to-date requirements with respect to key sizes and
    the DNSSEC operations.

---

DNSSEC Policy & Practice Statement Framework
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework

Abstract

      This document presents a framework to assist writers of DNSSEC Policy
      and Practice Statements such as Domain Managers and Zone Operators on
      both the top-level and secondary level, who is managing and operating
      a DNS zone with Security Extensions (DNSSEC) implemented.

      In particular, the framework provides a comprehensive list of topics
      that should be considered for inclusion into a DNSSEC Policy
      definition and Practice Statement.

--

DPS framework (slides)
<http://brussels38.icann.org/meetings/brussels2010/presentation-dnssec-dps-framework-ljunggren-23jun10-en.pdf>

DNSSEC in Sweden: Five Years of Practical Experience (slides)
<http://www.gc-sec.org/Events/Documents/AnneMarie%20Amel-2010-06-Rome-DNSSEC-workshop.pdf>

Root DNSSEC docs
----------------

Root DNSSEC - documentation (many documents)
http://www.root-dnssec.org/documentation/

IANA DNSSEC Information
https://www.iana.org/dnssec/

Individual DPSs
---------------

DNSSEC Practice Statement for the Root Zone KSK Operator
https://www.iana.org/dnssec/icann-dps.txt

Verisign DNSSEC Practice Statements
(.net, .edu, Signing Services, root zone ZSK operator)
https://verisigninc.com/en_US/repository/index.xhtml

RIPE DNSSEC Policy and Practice Statement
http://www.ripe.net/rs/reverse/dnssec/dps.html

DNSSEC Practice Statement (DPS)  -- .se
http://www.iis.se/docs/se-dnssec-dps-eng.pdf

DNSSEC Practice Statement for the JP Zone (JP DPS)
https://jprs.jp/doc/dnssec/jp-dps-eng.html

---
end

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 26 Jun 2011 23:33:17 -0400

For example:
<https://www.iana.org/dnssec/icann-dps.txt>

On Jun 26, 2011, at 8:14 PM, =JeffH wrote:

> Not to say that having these concerns is misplaced, but the DNSop WG, as well as various DNS operators, have been thinking along these lines...
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane