Re: [dns-operations] [Ext] Re: in-addr.arpa. "A" server "loopback network" misconfiguration

[Kim Davies]

Hi Mark, Hi all,

Quoting Mark Andrews on Friday June 23, 2023:
> There should be an insecure delegation for 127.in-addr.arpa. In the 
> in-addr.arpa zone. IANA have instructions from the IETF to do this in RFC 
> 6303.
> There has been a ticket open for years with IANA to correct the missing 
> insecure delegations. 

I looked into this in our ticketing system. Our practice is to review
all open tickets at least weekly until they are resolved, so there are
no tickets that are left open indefinitely without activity.

In this case, it looks like we communicated with the relevant IETF Area
Director and were advised to take no further action. Since it is now
almost 6 years later, happy to take a fresh look at this and see what
may need to be done.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] in-addr.arpa. "A" server "loopback network" misconfiguration

[Kim Davies]

Quoting Viktor Dukhovni on Thursday June 22, 2023:
> 
> 1.0.0.127.in-addr.arpa. IN PTR ?
> 
> the "A" server response is wrong, it leaks an internal empty zone for
> "0.0.127.in-addr.arpa" for which there is no insecure delegation in
> the parent zone, so the unsigned denial of existence is BOGUS.

We will take a look at what is happening and report back.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Browser Public suffixes list

[Kim Davies]

Hi Jothan,

Quoting Jothan Frakes on Saturday August 27, 2022:
> I am really frustrated that the materials developed for IANA to share to
> avoid things like this were not distributed, as awareness would have led to
> earlier request, which in turn would have diminished the propagation timing
> gap with the browser side.

I'll confess to being quite perplexed because it sounds like IANA has
dropped the ball, but I am at a loss as to what IANA materials you
are referring to. I am not aware of any materials developed for IANA
to distribute, and we don't have an existing practice of relaying
information about third party projects to TLD managers. Apologies if
I've completely overlooked something.

I know you and I have had discussions in years past about other TLDs
that were missing from the PSL, and I've asked if there were ways IANA
could contribute. The impression I came away with was the PSL guarded
its independence and therefore there wasn't a role for IANA. In light of
that I'd shared with you some sample code that I felt could immediately
be used by the PSL maintainers to identify gaps, or built upon to
trigger additions in your workflow:

https://gist.github.com/kjd/3b1141451c77e50e0ab1120caac40072

If PSL is still not automatically recognizing new TLDs, I would suggest
it would still be a better approach to automate rather than putting
the burden on each and every TLD manager to manually request to be
added. After all, the underlying truth of a TLD's existence is easily
ascertainable with existing tools without adding extraneous workflow
steps.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Deprecating infrastructure .INT domains

[Kim Davies]

Colleagues,

I wanted to draw your attention to an Internet Draft we’ve developed, its goal 
is to formally deprecate a number of historic “.int” domains that were 
designated for Internet infrastructure purposes decades ago and appear for all 
intents and purposes obsolete. After some limited consultation on developing 
the approach so far, it would be useful to get some additional eyes on it so we 
have greater confidence there is nothing we’ve missed.

You can find the draft at 
https://www.ietf.org/archive/id/draft-davies-int-historic-01.html

It’s a short document, but at its heart we’ve identified the following domains 
that are referenced in places but seem to be obsolete:

atma.int, ip4.int, nsap.int, rdi.int, reg.int, tpc.int

Most of these are not delegated in the int zone any longer, but there are 
lingering references online to them.

Thanks in advance for any insight, and apologies if you get this message in 
duplicate,

kim




___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone

[Kim Davies]

Hi Warren,

Quoting Warren Kumari on Thursday August 20, 2020:
> This seems to have died down, so I figured I'd ask if you'd managed to
> pull anything like consensus out of it?

This thread has triggered discussions in other groups, and I've been
asked to present the topic to three of them in the coming few weeks.
I've not received any feedback that the approach has fundamental flaws,
but I am eager to hear of any concerns or perspective they have before
taking additional steps.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone

[Kim Davies]

Hi Paul,

Quoting Paul Wouters on Wednesday August 12, 2020:
> 
> > My take is this is a high-level expression of an operational change
> > that is notable, but the details that would underly its implementation
> > are not. Of course detailed plans are needed by the operator and other
> > directly involved parties, as is the case of any other zone, but such
> > ephemeral details are probably not best suited for RFCs.
> 
> I am confused as to what would happen. Either, the root zone operators
> will drop the .arpa zone, or they will keep serving it under a new
> agreement. 

It is worth noting that basically the entire publication and distribution of
the arpa zone is not contracted or otherwise covered by any agreements: 

* The RZMA, where ICANN contracts Verisign to produce and disseminate the
  root zone to the RSOs, has no mention of .arpa;

* Agreements that exist right now for individual RSOs don't mention .arpa
  ;

* RFC 2870, while superseded, for a long time stood stating root servers
  "MUST NOT provide secondary service for any zones other than the root
  and root-servers.net zones"

> If they keep servigin it, either they will use the same
> nameservers as for the root, or they will use different nameservers. If
> they use the same nameservers, then in practise nothing will change except
> some paperwork and people will still not want the new fancy RRTYPEs in
> the .arpa zone. If they will use different servers, why can't they do
> that right now?

Changing the hostnames of the nameservers appears to be a precursor to any
other kind of reconfiguration. It seems certain that .arpa can't have any
meaningfully differentiated service so long as it is using
{a-i,k-m}.root-servers.net as its NS-set.

But that doesn't mean the end goal is necessarily full separation!

The only concrete outcome proposed in this document is those hostname
changes, and there is text that notes fuller separation would comprise
changes in other areas as well. I think the need to progress down those
paths, and the pace required, will depend on a number of factors such
as whether there are new demands for the zone and whether the current
parties are willing to continue their roles. Just as for any other zone
operator, changes in the operational environment and evolving demands
for the zone will inform future planning.

> I am concerned that de-coupling .arpa might lead to the zone being
> underserved. Or that IETF needs to start budgeting for running this
> zone in the future itself. That might lead to instability as we
> currently don't even have enough money to pay salaries due to a
> pandemic and are temporarilly charging for things that we normally
> do for free (online participation).
> So from a risk management point of view, I see no reason for the
> IETF to make a change, unless we can guarantee some longterm plan
> for financing running the .arpa domain.

Because of the lack of contracts or agreements noted above, I don't
think there are any fundamental guarantees of service today and
presumably the current operators could withdraw service at their
discretion. Leaving the current configuration unmodified provides no
certainty of future success.

Identifying the proper operational expectations, and putting in place
any necessary agreements around that, I think is a component of maturing
the approach. Given running this domain is part of the IANA functions,
my assumption is any additional costs borne in operating it would likely
be borne as part of how the IANA functions are funded. This would mean
there would be public review and engagement process associated with
budget development on an annual basis.

kim

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone

[Kim Davies]

Hi Doug,

Quoting Doug Barton on Saturday August 08, 2020:
> 
> I'm not convinced by this draft as-is that there is any purpose to making
> this split. You refer several times to proposed novel changes to the ARPA
> zone that can't be done because of the entanglement, where are the
> references?

The challenges of the current configuration are manifest.

On a day-to-day operational level, we have two distinct zones served
by the same authorities, one a child of the other. Edits to the NS-set
of one zone need to be coordinated with the another. When we change
the IP address of a root server, two parallel coordinated edits need
to be done synchronously in the arpa zone and the root zone. Approval
processes differ for both. As a consequence there are special-casing
rules throughout our root management code and business processes that
specifically pertain to "arpa" that we are keen to get rid of. Can
we continue to cater for it? Certainly. But there appears to be no
compelling reason to want to strive to persist this.

Distinct from that, the conservative approach to administration
of the root zone inhibits potential applicatons of the arpa zone.
Just one example is the notion of adding a DNAME record for an arpa
application - because such a record would be served using the shared
root infrastructure, it is assessed there would be the significant
impediment associated with all the due diligence that would go with
that. It is foreseeable that any future evolution of the arpa zone to
use new resource record types or other kinds of configuration changes
will be analysed through the lens of root operations so long as they
operate on shared infrastructure.

> I realize that I-Ds are not supposed to be used as protocol
> references, but this is an example of where referring to them as works in
> progress is justified. Folks reading the RFC 10 or 20 years from now won't
> have the context that some current readers do, and for that matter, I don't
> have it now. Without some way to judge the value that would accrue from
> making this change, it's impossible to justify the herculean effort it would
> take to do this change, and do it properly/safely.

I don't foresee it as herculean, in fact, I think it represents
straightforward changes that will result in significant benefits. Other
zones, including top-level domains, change their authorities often and
it is not considered problematic — it is considered a normal part of
zone administration. The root zone is special as the entry point to the
DNS, but arpa is only drawn into this specialness by virtue of being on
shared infrastructure with the root.

> Assuming you convince us that the change is needed, I suggest that you
> change the ns name space to arpa-servers. I understand the value of keeping
> the name server host names short, but given the unique role of the ARPA zone
> I can easily imagine a scenario where it would be desirable to use the ns
> name space for something else down the road. I do realize that even today
> there are places in the world that are bandwidth-constrained, but using the
> same label across the NS set allows for compression which would essentially
> eliminate the "cost" of the longer label.

Perhaps to level-set: the goal was not to convince this mailing list of
the need for a change, it was to get additional perspective to identify
potential problems that have not been foreseen with the approach. We
manage the arpa zone at the behest of the IAB, and in the context of
that relationship we'll ultimately agree the specifics of how to evolve
the zone.

> Whatever the label turns out to be, I think you should make clear whether or
> not (and I assume not) you intend for the name server name space to be a
> delegated subzone, or just a host name convention, and why. It's a fairly
> nitpicky detail, but when you're making an operational plan that has this
> many moving parts, with this many players in the game, and affecting so many
> end users, I don't think it hurts to over-specify the requirements a little.
> :)

What do you see as the operational impact of one versus the other? I
think before going into very specific levels of detail it should be
rooted in a discussion about the side-effects you are trying to avoid
and why they are specifically relevant to the arpa zone.

> Finally, by definition splitting the operations of the ARPA zone away from
> the current process increases the attack surface.

Can you elaborate further what you mean here? Are there any unique risks
that pertain to arpa you've identified, or the same general risks as
when you change the NS-set of any zone?

> You'll have more/different
> eyes and hands at every step of the way. That should be acknowledged in the
> Security section. I would also like to see a robust description regarding
> how the integrity of the content of the zone is going to be secured, how the
> change process is going to work, etc. As written the Security section
> basically says, "It'll be like 

Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone

[Kim Davies]

Quoting John Levine on Friday August 07, 2020:
> 
> One can download the .ARPA zone files from the same places as the root
> zone, by https or ftp from internic.net and by AXFR from two icann.org
> servers. Will that change? As far as I know it's not documented
> anywhere; you just have to know it's in the same places as the root.

No changes planned in that regard, and my expectation is all the same 
locations for download will continue to work as today.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone

[Kim Davies]

Hi Phillip,

Quoting Phillip Hallam-Baker on Friday August 07, 2020:
> 
> What has never been fully appreciate is that while the root zone is the
> apex of the naming hierarchy. The .arpa zone is potentially the apex of the
> trust hierarchy.

Any zone has the potential to be the apex of a trust hierarchy. Is there
any specific proposal pertaining to "arpa" itself that it be used in
such a way where it wouldn't be suitable to inherit trust using existing
mechanisms in the DNS?

> We should do it right because the .ARPA zone is evolving into the trust
> root of the legacy telephone system. 

I presume this is referring to the "e164.arpa" zone which is a distinct
zone from "arpa" and administered separately.

> What this means in practice is that as with the DNS apex root servers, the
> .ARPA root servers need to have stable, static IP addresses that change
> infrequently with long notice times. The zones should be signed using
> appropriate ceremonies.

I am not aware of any proposal that would require this. I suspect if
future technologies need different operational parameters for .ARPA
along these lines, then it would specified in the requirements for that
technology (i.e. as "IANA Considerations"), and the zone's operations
would adapt accordingly upon adoption. In the absence of any specific
reason to do this, placing an arbitrary requirement that the zone have
long-lived static IP addresses is burdensome and seems to run counter to
giving .ARPA new flexibility.

> So what I would suggest is:
> 1) Separate the hosts for .ARPA from the root zone hosts.
> 2) Create a separate set of HSMs for .ARPA but administer them within the
> ICANN root ceremony
> 3) Transition ARPA to next generation technology which avoids the need to
> meet to perform ceremonies in person.

Nothing in this proposal prejudices changes to how the KSK for the
"arpa" zone may evolve in the future. I would suggest any effort
to define new baseline requirements for the "arpa" KSK be handled
separately as they are distinct from the objective of this draft. The
goal here is to delink the day-to-day administration of .ARPA from
the root zone such as that .ARPA would be treated like any other TLD,
allowing it to evolve in its own direction at its own pace.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Separating .ARPA operations from the root zone

[Kim Davies]

Folks,

I wanted to draw attention to an Internet-Draft under development that seeks to 
remove the unique interdependency that the .arpa zone has with the root zone, 
by virtue of the zone being served by the root servers:

https://www.ietf.org/id/draft-iana-arpa-authoritative-servers-01.txt

We are looking for additional review of the proposed changes before taking 
further steps.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Contingency plans for the next Root KSK Ceremony

[Kim Davies]

Folks,

As a follow-up to the discussion a few weeks ago, we are proceeding the next 
root zone key signing ceremony tomorrow, as originally scheduled, but with 
reduced in-person participation and a limited agenda. We’ve put together a Q 
on our approach which is available at 
https://data.iana.org/ksk-ceremony/41/KC41_qa.pdf and a general interest blog 
article has been posted by ICANN at 
https://www.icann.org/news/blog/conducting-a-key-signing-ceremony-in-the-face-of-covid-19

The ceremony itself is scheduled to start at 1700 UTC on Thursday, the script 
and livestream will be available at https://www.iana.org/dnssec/ceremonies/41

Thanks everyone for your thoughtful input that went into the approach.

kim

"Kim Davies" mailto:kim.dav...@iana.org>> wrote:

The IANA team, and the broader ICANN organization, have been giving significant 
thought to the Coronavirus pandemic and its impact on root zone KSK operations. 
Managing the KSK is centred on conducting "key signing ceremonies", where 
trusted community representatives (TCRs) attend from around the world to 
witness utilization of the root zone KSK private key. This approach seeks to 
engender trust in the broader community that the key has not been compromised, 
in addition to more typical controls such as third-party auditing.

…
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Kim Davies]

Quoting Bob Harold on Monday March 30, 2020:
> Just wondering, have you asked if 3 of the TCR's might be willing to
> actually come?  With enough protections, would that be possible

We've re-validated the availability of TCRs and others who had already
committed to come. Some have withdrawn, either for personal reasons or
government/company restrictions, and some are impacted by unavailability
of air travel.

Importantly, it is hard to predict with any certainty how the situation
will continue to evolve.

At this time, our assessment is we don't have a high confidence we can
meet normal quorums for attendance. If the prognosis improves in the
coming weeks that could be revised, but we want to plan for a minimal
ceremony and identify how to best mitigate potential concerns with the
approach.

kim

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Kim Davies]

Hi Sergey,

Quoting Sergey Myasoedov on Friday March 27, 2020:
> 
> There is no specific concern. Any KSK operation can be performed without the 
> physical 
> TCRs presence. There is no other source of confidence except TCRs, and their 
> absence 
> or accessing the private key without their presence isn’t good for trust.

Hopefully our approach does not depend solely on TCRs for confidence.
We've consciously sought to operate a highly transparent process
that allows anyone who is interested - not just TCRs - to witness
proceedings and be involved, either in person or remotely. Further,
we are audited by a third-party audit firm using the SOC 3 framework
(formerly SysTrust), and have received unqualified opinions each year
since we first started in 2010: https://www.iana.org/about/audits

Another key protection is we seek to disseminate all the relevant
materials from the ceremony. All audit footage, software used, and
the logs and artefacts generated are posted online for download and
inspection.

Certainly if there is a perception that trust hinges critically on TCRs,
we've either not communicated the breadth of the controls well enough,
or we need to do more to instill trust. Just as the security envelope
for the KSK involves multiple overlapping physical security controls,
maintaining trust in KSK management should involve multiple overlapping
trust mechanisms to satisfy the community.

> I understand the extraordinariness of the moment, and if you have no choice, 
> you’ll jump to 
> Option 2 and Option 3 then. Is the disaster recovery procedure (Option 3) the 
> one that should’ve 
> been done on Verisign’s disaster recovery site? Does it require to access the 
> cards? Or we’re 
> discussing the non-disaster remote ceremony?

We do not have any disaster recovery sites, and we do not use any
sites operated by Verisign. We have two replica sites which, in normal
operations, we alternate holding key ceremonies. We can use either to
perform a key ceremony. Verisign operates their own infrastructure as it
pertains to managing the ZSK for the root zone.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Kim Davies]

Quoting Sergey Myasoedov on Thursday March 26, 2020:
> 
> > • Using 3 TCRs’ credentials, either by having their access key 
> > transferred to us in a secure manner in advance of the ceremony, or by 
> > drilling the safety deposit box that holds their secure elements.
> 
> Accessing the credentials without the TCRs present will shatter confidence in 
> TCR model. Better avoid that.

It would be good to better understand this concern, because we are
facing scenarios where we may not have a choice but to do it in this
manner. What is your specific concerns about the lack of physical TCR
participation, and what would be the best way to remediate them? 

Bear in mind our goal is to continue to involve TCRs remotely in an
active role as much as possible, much in the same way they would
participate in a regular ceremony. They would oversee custody of their
credential, along with having the opportunity to interject and advise
along the way.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Contingency plans for the next Root KSK Ceremony

[Kim Davies]

Colleagues,

The IANA team, and the broader ICANN organization, have been giving significant 
thought to the Coronavirus pandemic and its impact on root zone KSK operations. 
Managing the KSK is centred on conducting "key signing ceremonies", where 
trusted community representatives (TCRs) attend from around the world to 
witness utilization of the root zone KSK private key. This approach seeks to 
engender trust in the broader community that the key has not been compromised, 
in addition to more typical controls such as third-party auditing.

In light of world events we have developed contingency plans around how to hold 
key ceremonies in the short term. To that end, we identified a graduated set of 
options, in summary:

  1.  Hold the next ceremony as planned on April 23, with a quorum of 
participants globally.
  2.  Hold the next ceremony on a different date using only US-based TCRs.
  3.  Hold the next ceremony using our disaster recovery procedure, which 
provides for a staff-only ceremony (i.e. no TCRs would be physically present).
In general, our goal has been to navigate from Option 1, and if that is not 
possible, Option 2, and so on. However, at this time, our focus is on 
developing a plan around Option 3.

The ceremony is currently scheduled unusually early in the quarter (it is 
typically held in May), and needs to be held to generate signatures that will 
be needed in production for July. Our contingency plan is comprised of:


  *   Holding the ceremony with a bare minimum of staff (approximately 6);
  *   Using 3 TCRs’ credentials, either by having their access key transferred 
to us in a secure manner in advance of the ceremony, or by drilling the safety 
deposit box that holds their secure elements.
  *   Holding the ceremony under typical audit coverage, allowing for remote 
witnessing of events by all, plus providing additional opportunities for TCRs 
to stay involved in the process remotely.
  *   Signing key materials to cover one or more subsequent quarters, to 
provide relief from the need to necessarily hold ceremonies later in 2020 if 
circumstances disallow it. (The additional signatures would be withheld 
securely until they are needed.)
Our key management facilities were designed with the disaster recovery 
capability of performing staff-only ceremonies in mind, but this is a 
significant shift from normal operations and we want to promote broader 
community awareness of this work. Those directly involved in key ceremonies - 
the trusted community representatives, our vendors and auditors - have been 
consulted and are broadly supportive of this effort.

Should there be any specific feedback you would like to share with our team, 
please let me know or respond to this thread. We will take it into 
consideration as we finalize our plans.
Thank you for your support,


Kim Davies
VP, IANA Services, ICANN
President, Public Technical Identifiers (PTI)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: root? we don't need no stinkin' root!

[Kim Davies]

Quoting Rubens Kuhl on Wednesday December 11, 2019:
> 
> That's not of what RSPs (Registry Service Providers), ICANN GDD and ICANN 
> IANA have been doing in RSP transitions. What has been working best is to 
> double DS the zone with losing KSK and gaining KSK, have both RSPs sign each 
> other ZSKs and NSs, and replace all DNS servers at gaining RSP, then losing 
> RSP, then IANA.

To explain a little bit more detail on the philosophy behind the IANA
approach: we are seeking to reduce risk wherever possible, particularly
with fundamental changes that have the potential to significantly
impair a TLD if they are executed incorrectly. These includes scenarios
such as a complete change of the NS-set (the new NS-set may not be
proven to handle the full production load for the TLD or otherwise be
misconfigured), and changes to the DS-set (where we want to avoid taking
a leap-of-faith the TLD will validate correctly when rolling over to an
unproven key).

We try to mitigate these risks by encouraging staggered or overlapping
approaches to key rollovers and to NS-set changes. For NS-sets, the
theory is that some of the population of the staggered set will still be
from the current, proven set and should be able to at least partially
service TLD resolution. For DS changes, we have had instances where
TLD managers have requested a DS record be listed in the root, and to
take in on faith without evidencing the associated DNSKEY, only to find
upon later rollover that it was the wrong fingerprint, resulting in an
emergency response to restore a valid delegation to the TLD.

Listing the DNSKEY in the zone in advance, even if it is not yet used
for signing, also provides a valuable safeguard. It proves the requester
has authorship, either directly or indirectly, of the TLD's zone file.
This is a benefit that also accrues from asking for NS-set changes to
be reflected in apex of the TLD zone first, and for glue changes to be
first reflected in the host's authoritative A/ records. It serves
as an additional check to make sure any change to the zone is properly
authorized at the root zone level because it has already been validated
through publication in the child, which is under the TLD operator's
control.

Requesters can seek to perform the changes differently and we evaluate
these on a case-by-case basis. We are sympathetic to operational
realities and specific complexities of certain changes, which is why
you may see changes that do not always adhere to these approaches. In
general, through, we strongly advocate migrations happen in such a
fashion that minimize potential risk to basic resolution, even if it is
at the cost of some potential additional administrative complexity
in making the change.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Fwd: Replacement of Root KSK Hardware Security Modules

[Kim Davies]

.

Risk: All new production HSMs share a common defect.
Mitigation: It is possible that if all four HSMs are from the same production 
batch, they may have common flaws (such as bad battery composition) that would 
compromise the redundancy in place. To mitigate this risk, ICANN worked with 
the vendor to ensure the HSM units are comprised of models with different 
manufacture dates and contain batteries that were built in different production 
runs.

Questions and Answers

Q1: Why do the HSMs need to be replaced, and not just the batteries?
A1: While the HSMs can be reconditioned with new batteries, they must be 
returned to the vendor to perform that procedure. ICANN will replace the HSMs, 
rather than recondition the units, to ensure the cryptographic key material 
does not leave the secure Key Management Facilities.

Q2: How does this project involve a future rollover of the Root KSK?
A2: This project is distinct from the project to replace the existing Root KSK 
with a new Root KSK (known as a “rollover”). HSM issues relating to the 
rollover will be considered by the Root KSK Rollover Design Team.
Separation of the HSM replacement project from a Root KSK rollover is 
considered beneficial to allow time for the Rollover Design Team to fully 
develop their approach without being influenced by operational pressures 
relating to HSM replacement.

Q3: What consideration was made in selecting the replacement HSMs?
A3: ICANN procured the most recent HSM model, the AEP Keyper Plus, from the 
vendor used to provide the HSMs that are currently in production. This model 
meets FIPS 140-2 Level 4 security certification, which is a requirement for the 
Root KSK in the IANA Functions contract. This model also allows for the 
importing of the Root KSK from the older models without needing to regenerate 
the Root KSK. The newer HSM model was selected rather than the current HSM 
model in ICANN’s production model as the expected lifetime of support from the 
vendor is greater.

Q4: How many trusted community representatives are needed to replace the HSMs?
Q4: ICANN has determined that three trusted community representatives is the 
minimum number needed to export the root KSK from the existing production 
devices, and import them into the new devices. This process does not require 
generation of a new set of “SO” and “OP” cards, and therefore does not require 
the entire set of Cryptographic Officers to be present. The existing Recovery 
Key Share Holders’ credentials will continue to work with the new HSMs.

With kindest regards,

Kim Davies
Director, Technical Services
ICANN

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD

[Kim Davies]

On Sep 11, 2014, at 7:40 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
 
 https://data.iana.org/TLD/tlds-alpha-by-domain.txt
 
 Yes, but that's what's already in fact delegated, not what is about to
 (so it's the same as just getting the root zone, AFAICT).  I think
 what would have been better is a feed that said, Here's what we plan
 to delegate next, without perhaps giving a time.  But I understand
 why ICANN decided it couldn't do that.

I guess it would be helpful to better understand the use cases this
information would be used for prior to delegation to inform how
what is already published could be expanded.

From my perspective, we don't have a guarantee that a specific TLD
is going to be delegated until we see it with our own eyes being
propagated to the root servers. The prospect of a prod TLD, along
with all the other candidate new gTLDs, was announced on 13 June
2012. Since then with the various strings we have had increasing
levels of confidence certain strings are likely to be delegated.
From application, there are a series of steps including initial
evaluation, pre-delegation testing, contracting, delegation request
etc. with the passing of each step making it increasingly more likely
a given string will be delegated.

Verisign does the final publication and dissemination of a revised
root zone, and signals back to ICANN shortly prior to a root zone
push (minutes or hours) that a particular root zone change is
ancticipated to be reflected in the next zone push. I think even then
it still does not provide a guarantee that it won't be pulled back due
to a last minute issue.

I would ask, what is gained by tracking in the hours, days or weeks
in advance that a TLD is likely to be delegated? How will it help
compared to having the list from 2012 of all the strings being
considered already in hand?

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Official WHOIS redirector for TLDs

[Kim Davies]

On Mar 19, 2014, at 10:30 AM, Florian Weimer f...@deneb.enyo.de wrote:

 Is there are offical, documented WHOIS redirector for TLDs with some
 long-term interface stability.  WHOIS.IANA.ORG might do the job, but I
 couldn't find official documentation pointing to it.

The WHOIS server at whois.iana.org will return a key-value pair of refer and 
a referral WHOIS server when you ask for a resource it knows about, but it is 
not returning the most specific answer for, and has knowledge of a more 
specific WHOIS server that should be able to service the query.

As an example, attached is a config file for jwhois that has been slightly 
modified to fallback to these referrals. (This is a minimal change patch, but 
the config has the potential to be greatly simplified further because 
whois.iana.org provides referrals for IPv4, IPv6, AS number blocks, etc. as 
well)

We don't have formal documentation of the service, but you can find a blog post 
we made explaining the functionality at 
http://blog.icann.org/2010/05/test-iana-whois/

Regarding interface stability, while we have no formal commitments in this 
area, we have no intention to change the current format (in the sense of 
parsing the output) and only potentially add new fields to it in the future.

kim


jwhois.conf
Description: jwhois.conf


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] Trusted Community Representation for Root KSK

[Kim Davies]

Hi folks,

ICANN is currently performing a consultation on how to evolve the participation 
of Trusted Community Representatives in the management of the root key signing 
key. I think this consultation is of particular interest to this group as 
ultimately these TCRs are there to instill trust in the DNS operations 
community that the KSK is being managed in a proper fashion.

I'd encourage you to provide feedback to this consultation — available at 
http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan14-en.htm
 — by 11th February. It is important we have a model of TCR participation that 
is satisfactory to the community.

For convenience, here are the terms of reference replicated:

Background

Since July 2010, the DNS Root Zone has been secured using DNSSEC[1]. The model 
of using DNSSEC in the DNS Root Zone revolves around a “key signing key” (KSK) 
that is managed by ICANN in two secure facilities. Four times a year, a 
ceremony is conducted at these facilities to perform operations involving the 
KSK. As a key part of this process, a minimum of three from a pool of 21 
trusted community representatives (TCRs) attend each ceremony to enable access 
to the secure materials, to witness the procedure, and to attest that the 
ceremony was conducted properly[2].

Each ceremony is attended by ICANN staff, the TCRs, representatives of the Root 
Zone Maintainer (Verisign), representatives of an independent audit firm 
retained by ICANN to monitor the process, and often additional external 
witnesses. Ceremonies are recorded by three audit cameras and webcast online. A 
typical ceremony lasts approximately four hours, and involves a process of 
temporarily removing the key signing key from a safe and performing key-signing 
operations in a secure manner following a formal script. The script is designed 
to perform each operation in a transparent manner to ensure the key signing key 
is only used for its proper purpose, and there is no ability for its contents 
to be disclosed for other purposes. Materials from each ceremony — such as the 
scripts, video recordings, and system output — are posted online[3].

De-briefings and discussions are conducted post-ceremony, where participants 
discuss how to improve future ceremonies. This feedback helps inform the 
evolution of the KSK ceremony to be both efficient and effective, while 
ensuring maximum trust in how ceremonies are performed.

The TCRs were selected[4] from the global community based on a number of 
criteria[5]. These selection criteria relate to the volunteers ability to 
travel to ceremonies, conscientiously oversee the process, ensure transparency 
in its operation, and ultimately contribute to the broader community's trust 
that the private component of the key signing key has not been compromised. The 
TCRs are privately funded volunteers who are not reimbursed or compensated by 
ICANN for their participation nor their expenses. The original TCR proposal was 
silent on the length of service of individual TCRs.

Of the 21 TCRs, seven are credentialed as “crypto officers” (COs) for each of 
the two facilities, and the remaining seven act as “recovery key shareholders” 
who only participate in ceremonies in the event the requisite number of COs are 
unable to participate or there is a need to rebuild the KSK following an 
unforeseen event. Of the seven COs for each facility, ICANN aims to have four 
attend each ceremony, with an absolute minimum of three required to 
successfully perform a ceremony. Each facility hosts two ceremonies per year, 
approximately once every six months. In practice, a TCR will attend at minimum 
one ceremony per year, and some will attend two in order to ensure sufficient 
attendance.

Of the initial pool of 21 TCRs, one has resigned and been replaced from the 
pool of recovery key shareholders. No TCR has been removed owing to the other 
three criteria for replacement in the TCR selection document, relating to lack 
of integrity or trustworthiness; assumption of a conflicting role within a root 
management organization; or being unable to serve in their position.

Based on feedback from the current TCRs and our experience from the first 14 
ceremonies, we are reviewing what changes, if any, should be made to the 
current model of TCR participation.

Comments

Comments are welcome on any aspect of the consultation, and specifically on the 
following questions:

1. Is the current TCR model effectively performing its function of ensuring 
trust in the KSK management process?
2. Is the current size of the TCR pool appropriate to ensure sufficient 
participation in the ceremonies, while not overburdening the availability of 
specific volunteers?
3. Should there be a minimum level of participation required of a TCR in order 
to be considered to be successfully discharging their duties?
4. There is no standard provision to refresh the list of TCRs except when they 
are replaced due to inability to 

Re: [dns-operations] It's begun...

[Kim Davies]

On Oct 23, 2013, at 1:11 PM, Rick Wesson 
r...@support-intelligence.commailto:r...@support-intelligence.com wrote:

Does ICANN have a root-zone announce list? I remember hearing about it being 
developed, but can't locate the list subscribe.

We don't have a list yet, partly because we have a number of new notification 
services we've been asked to roll out for different IANA registries, and it 
would be nice to roll out a common approach for IANA notifications so you can 
get notifications from the mixture of registries that interest you.

For the root zone, it would be good to get some feedback on what level of 
granularity of notifications would be most useful. There is a spectrum of 
notifications possible — we could notify of every change in the root zone and 
root zone database, which would include such things as when a contact person 
changed their telephone number; all the way to only notifying of key 
developments (new TLDs, newly signed TLDs, key rolls, etc.) I suspect there is 
no consensus answer, but would be interested to know what folks would find most 
useful for them.

By way of illustration, this is the internal notification I get, which only 
relates to zone data:


From: Kim Davies kim.dav...@icann.orgmailto:kim.dav...@icann.org
Date: October 23, 2013 at 11:35:00 PDT
Subject: Root discrepancies for serial 2013102301


by   (rz) ds   43875 7 1 
B5667014733F0FD07D096B2FA2AD175186ADF48C
 (rz) ds   43875 7 2 
27A33067E54A8C4CEE091DB22156EF02A79A76CCC1E48D6D195DFEF6D520C48E
xn--80asehdb (rz) auth 
anycast10.irondns.nethttp://anycast10.irondns.net 195.253.64.12 2a01:5b0:4::c
 (rz) auth 
anycast23.irondns.nethttp://anycast23.irondns.net 195.253.65.11 2a01:5b0:5::b
 (rz) auth 
anycast24.irondns.nethttp://anycast24.irondns.net 195.253.65.12 2a01:5b0:5::c
 (rz) auth 
anycast9.irondns.nethttp://anycast9.irondns.net 195.253.64.11 2a01:5b0:4::b
 (rz) ds   54606 10 2 
A1A13FCD0AFB413657352EBA09765C81E0BA0AF0B8452F03EB0D0E4C9661241D
xn--80aswg   (rz) auth 
anycast10.irondns.nethttp://anycast10.irondns.net 195.253.64.12 2a01:5b0:4::c
 (rz) auth 
anycast23.irondns.nethttp://anycast23.irondns.net 195.253.65.11 2a01:5b0:5::b
 (rz) auth 
anycast24.irondns.nethttp://anycast24.irondns.net 195.253.65.12 2a01:5b0:5::c
 (rz) auth 
anycast9.irondns.nethttp://anycast9.irondns.net 195.253.64.11 2a01:5b0:4::b
 (rz) ds   61281 10 2 
FD5803E5D6CA1B8B5B3345B8E6AEA0E640988D973AE153713A7BC890A84E3400
xn--ngbc5azd (rz) auth a.nic.xn--ngbc5azd 2001:dcd:1::3 37.209.192.3
 (rz) auth b.nic.xn--ngbc5azd 2001:dcd:2::3 37.209.194.3
 (rz) auth c.nic.xn--ngbc5azd 2001:dcd:3::3 37.209.196.3
 (rz) auth d.nic.xn--ngbc5azd 2001:dcd:4::3 37.209.198.3
 (rz) ds   20736 8 1 
0AC95C7D70A0A3CCB3E8351F6416663B941230DD
 (rz) ds   20736 8 2 
851A2DD716C38C5325818FB56E53D8F2E340C098F8AE9DC531601F49F4D8B943
xn--unup4y   (rz) auth demand.alpha.aridns.net.au 2001:dcd:1::7 
37.209.192.7
 (rz) auth demand.beta.aridns.net.au 2001:dcd:2::7 
37.209.194.7
 (rz) auth demand.delta.aridns.net.au 2001:dcd:4::7 
37.209.198.7
 (rz) auth demand.gamma.aridns.net.au 2001:dcd:3::7 
37.209.196.7
 (rz) ds   27607 8 2 
6C4C1CBD05BCA28A60B397ED8AC77783D7592EB50028FD3AE8A59BB5758984D3



kim

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] FYI: SAC057 - SSAC Advisory on Internal Name Certificates

[Kim Davies]

On Mar 15, 2013, at 10:57 AM, Robert Edmonds edmo...@isc.org wrote:
 
 i certainly hope the reference to hr being a local or internal or
 non-unique name is a mistake and that CAs would absolutely refuse to
 issue certs for names that are the same as a really existing TLD:
 
http://www.iana.org/domains/root/db/hr.html

We get a steady stream of requests from CAs to endorse certificates for 
non-existent
hosts under .int, because .int is used as the applicant's internal network.

On the bright side, these are CAs that are at least making an effort to check 
with the
registry for a definitive answer.

kim
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs