.ORG is signed

Colleagues,

On behalf of PIR Technical Support I would like to announce that as of  
today, 2009-06-02, at 16:00 UTC .ORG is DNSSEC signed.

Press release at http://www.afilias.info/afilias+signs+org+zone

The following KSK is now valid for .ORG

org.			IN DNSKEY 257 3 7 (
				AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDo
				dnZ9IMh0bwMcYaVUdzNAbVeJ8gd6jq1sR3VvP/SR36mm
				GssbV4Udl5ORDtqiZP2TDNDHxEnKKTX+jWfytZeT7d3A
				bSzBKC0v7uZrM6M2eoJnl6id66rEUmQC2p9DrrDg9F6t
				XC9CD/zC7/y+BNNpiOdnM5DXk7HhZm7ra9E7ltL13h2m
				x7kEgU8e6npJlCoXjraIBgUDthYs48W/sdTDLu7N59rj
				CG+bpil+c8oZ9f7NR3qmSTpTP1m86RqUQnVErifrH8Kj
				DqL+3wzUdF5ACkYwt1XhPVPU+wSIlzbaAQN49PU=
				) ; key id = 21366

Please note that due to the use of NSEC3 this key should not be used  
with BIND versions less than 9.6.0.

Please refer to http://pir.org/dnssec for more information.

As always, please report operational concerns with any Afilias-hosted  
zone to <noc <at> afilias-nst.info>

dave

[matthew <at> dempsky.org: DNS trust dependencies for ICANN TLDs]

For information (or advices or ideas or jokes). You can read the whole 
thread online at 
<https://lists.dns-oarc.net/mailman/listinfo/dns-operations>.

From: Matthew Dempsky <matthew <at> dempsky.org>
Subject: DNS trust dependencies for ICANN TLDs
Date: 2009-06-11 03:02:20 GMT

I've assembled a collection of graphs of zone and name server trust
dependencies for each ICANN TLD at

    http://shinobi.dempsky.org/~matthew/dnstrust/graphs/

I've heard claims from some TLD operators that extra dependencies are
actually intentional, but I haven't yet heard any arguments to justify
that claim.  Can anyone here offer arguments in favor of making TLDs
dependent name servers other than the ones authoritative for that TLD?

I plan to automate regenerating the graphs on a regular basis and to
start contacting TLD operators to point out particularly egregious
cases (e.g., .cn is dependent upon 247 extra name servers, many US
based, because of a single NS record), but I thought I would first
raise the matter here in case anyone had useful feedback.

Thanks.

meeting slot assignment for Stockholm

Dear WG,

the draft IETF 75 agenda, available from <http://www.ietf.org/meetings/75/>
as a PDF, shows dnsop as scheduled on Friday morning 0900-1130.
Conflicts in the same slot:

	dhc, dtnrg, ippm, mip4, mpls, rrg, sipcore

As always, this is subject to change.

Please let Rob and me know requests for WG agenda slots.

-Peter
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Fwd: I-D ACTION:draft-pettersen-subtld-structure-05.txt

Hello all,

I have updated and refreshed the draft describing my suggestion for  
distributing Public Suffix/Effective TLD information.

The updates are based on implementation experience while adding support  
for the format to an internal version of Opera.

The online repository is based on and generated from the Public Suffix  
List, http://publicsuffix.org/ , as maintained by Mozilla, and our  
variant  of it is available under the Mozilla Tri-license (MPL, GPL, and  
LGPL) from our download location at http://redir.opera.com/pubsuffix/ .

See also  
http://my.opera.com/yngve/blog/2009/06/17/refreshed-subtld-public-suffix-drafts  
.

The associated draft draft-pettersen-dns-cookie-validate-05.txt has also  
been refreshed, and is used as a fallback in Opera's new Public Suffix  
implementation.

------- Forwarded message -------
From: Internet-Drafts <at> ietf.org
To: i-d-announce <at> ietf.org
Subject: I-D ACTION:draft-pettersen-subtld-structure-05.txt
Date: Mon, 22 Jun 2009 20:15:01 +0200

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Problems with DS change in registry/registrar environment

[On request from Olaf, also dnsop is included:ed]

I think this discussion have derailed a bit, while on the other hand  
explained somewhat to me what things are really creating problems.

We have a problem when "a domain changes hands" and the private DS key  
in some way is changed, should be changed, and sometimes is not  
changed as it should. We all agree that could lead to a blackout, but  
in many cases the blackout is not more serious than a normal blackout  
when NS is changed.

First a description on the issues:

1. We have three different kinds of changes that can happen:

1.1. Change of Registrar
1.2. Change of Registrant
1.3. Change of Domain Manager (DNS Hosting Provider)

2. We have when using epp some limited number of commands available

2.1. Transfer (change of registrar)
2.2. Update of holder in the domain object (change of Registrant)
2.3. Update of host in the domain object (change of nameservers)
2.4. Update of IP address in host object (change of IP address of  
nameservers)
2.5. Update of techc in the domain object (change of Techc) [rarely  
used even in thick registry situations]

First conclusion is that we see that the operations under (1) does not  

Re: Problems with DS change in registry/registrar environment

> -----Original Message-----
> From: dnsop-bounces <at> ietf.org [mailto:dnsop-bounces <at> ietf.org] On Behalf Of
> Subject: [DNSOP] Problems with DS change in registry/registrar environment
> 
> 
> Is this summary at least partially correct?

Partially, yes.
I agree with you that there is no match between DNS operations and the definitions of registry transactions
like you describe in 1 and 2.
That's not the problem however, or at least is solvable at a local registry level by defining correct procedures.
So let's not discuss the mixing up of roles like registrar, registrants, dns-operators, etc.
The only reason they matter is because in practice:
-95% of registrar changes INVOLVE a change of DNS operator
-95% of registrant changes INVOLVE a change of DNS operator
-10% of nameserver changes at a registry INVOLVE a change of DNS operator, in 90% of the cases they don't.

The problem is in any transaction that involves a dns-operator change for the zone.
Since this is a DNS discussion, let's not discuss registrars, registrants, etc.
I only want to know how to move a DNSSEC zone from one DNS operator to another one, without outage.

I don’t agree with you here:

> We have a problem when "a domain changes hands" and the private DS key
> in some way is changed, should be changed, and sometimes is not
> changed as it should. We all agree that could lead to a blackout, but
> in many cases the blackout is not more serious than a normal blackout
> when NS is changed.

In normal non-DNSSEC DNS, when an NS set changes, both versions of the truth are still accepted by DNS resolvers.

Re: Problems with DS change in registry/registrar environment

On 30 jun 2009, at 12.02, Antoin Verschuren wrote:

> So let's not discuss the mixing up of roles like registrar,  
> registrants, dns-operators, etc.
> The only reason they matter is because in practice:

Where have you got these numbers from?

> -95% of registrar changes INVOLVE a change of DNS operator
> -95% of registrant changes INVOLVE a change of DNS operator
> -10% of nameserver changes at a registry INVOLVE a change of DNS  
> operator, in 90% of the cases they don't.
>
> The problem is in any transaction that involves a dns-operator  
> change for the zone.
> Since this is a DNS discussion, let's not discuss registrars,  
> registrants, etc.
> I only want to know how to move a DNSSEC zone from one DNS operator  
> to another one, without outage.

Agree.

> I don’t agree with you here:
>
>> We have a problem when "a domain changes hands" and the private DS  
>> key
>> in some way is changed, should be changed, and sometimes is not
>> changed as it should. We all agree that could lead to a blackout, but
>> in many cases the blackout is not more serious than a normal blackout
>> when NS is changed.

Re: [dnssec-deployment] Problems with DS change in registry/registrar environment

On Tue, Jun 30, 2009 at 08:36:47AM +0200, Patrik Fältström wrote:
> [On request from Olaf, also dnsop is included:ed]

<hat "dnsop co-chair">
The discussion and input is very wolcome in DNSOP.  For reasons related
to "Note Well" <http://www.ietf.org/maillist.html> we'll not be able to
routinely approve cross postings.  That said, I'd humbly suggest we move
followups that help framing document updates to dnsop only.
</hat>

> changed as it should. We all agree that could lead to a blackout, but  
> in many cases the blackout is not more serious than a normal blackout  
> when NS is changed.

ack

> 1. We have three different kinds of changes that can happen:
> 
> 1.1. Change of Registrar
> 1.2. Change of Registrant
> 1.3. Change of Domain Manager (DNS Hosting Provider)

Terminology is crucial here and domain manager as well as domain operator
are ambiguous.  The entity changed under 1.3 is probably the one that has
the "hands" on the zone content and essentially holds the key(s).  The
former is often called the "zone maintainer".  Of course there are
popular scenarios more complicated than that, for example where a customer
can maintain - to a certain extent - the content of their zone through some
web or database interface that will then feed the primary master.  I'd assume
that DNSSEC will be transparently added by the service provider here and

Trust History draft

Hi,

Just new in the dnsop wg tools page:
http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00

This is the same version as draft-wijngaards-dnsext-trust-history-03,
but moved to the DNSOP wg.  I would like to request adoption of the
document.

Why?  I want to enable end users to use validators.  They use computers
that sometimes skip a month (holiday), or install software that is a
couple years old.  RFC5011 cannot keep up in that case, and this trust-
history can then be used to get the latest trust anchor.

This latest version has a number of features that I'll present in a
point list:
* Can detect trust point deletion, where the zone owner wants to
  un-sign the zone.
* Honors RFC5011 hold-down-timer.  Thus it cannot be used to work
  around the 5011 timers.
* Track SEP keys.  Access to the KSK is necessary to change the keyset
  for the zone.
* Uses a clean new RR type, for dnsext expert review, to help store the
  information in the DNS.

So, this way, software can include a DNSSEC trust anchor, which can be
used years later to fetch the latest trust anchor, while the DNS zone
uses regular rollovers.  After fetching the latest, software can then
use 5011 to track the anchor.  If the 5011 updates fail because the
machine was offline or the software is reinstalled, the history can

Re: [dnssec-deployment] Problems with DS change in registry/registrar environment

On Tue, 30 Jun 2009, Patrik Fältström wrote:

> A.3. Have the registry remove DS implicitly if domain is transferred to 
> registrar that does NOT handle DNSSEC.
>
> My suggestion is that we look carefully on option A.3. This does not imply 
> any changes to any pieces of the protocol, deployed operation or such. And

Note that if you remove the DS record from the parent, you should then wait
the TTL before allowing the transfer, or else you will still have the domain
go dark for those who validators that have the DS record cached.

Paul
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop