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.
In normal non-DNSSEC DNS, when an NS set changes, both versions of
the truth are still accepted by DNS resolvers.
As long as you make sure the same data is in the old and new zone
(except for the NS set), the general public doesn't notice anyting.
In the period between the delegation change at the parent and the
expire time of the old NS set, any answer in a resolver works.
There is no blackout DNS-wise if you handle it right.
With DNSSEC, it doesn't. Only one version of the truth works (only
one validates), leading to a partial blackout for those resolvers/
validators that still have the old DNSKEY in their cache.
I am talking about having two DS in the parent zone, and sure, if the
client have cached the old DS, while following the new NS, then there
will be a blackout.
A change like any of the above that implies change of DS is for the
parties that know what they are doing, "just like" any key rollover.
Further, the key rollover can, just like change of NS, happen
regardless of what kind of change we deal with (1.1, 1.2, 1.3) with a
minimum involvement of the donating registrar and Domain Manager:
1 New Nameservers are set up
2 Old zone is served on new nameservers
3 Old zone is signed on new nameservers
With whose key ? DNS-operator A or DNS-operator B?
Signed with new DS.
So, on the donating DNS operators servers you have the old DS and old
SIG. On the gaining DNS operator, you have the new DS and new SIG.
In the parent zone, you have both new and old DS.
4 Domain is transferred to new registrar
5 New Domain Operator is adding new DS to the old DS set
6 New Domain Operator is adding new NS
Don't get you here. Where does he do this?
Add the new NS to the parent zone.
7 New Domain Operator is removing old NS
8 New Domain Operator is removing old DS
I think this procedure does not work.
When you remove the old DS, the DNSKEY of the old zone is still in
caches.
That's the real issue.
I agree with this, but is it not the case that you only(!) get this
problem if the NS and DS are timing out at different points in time?
And you have a cached DS, while looking up a new NS from parent zone?
And if you do, do you not get the new DS as well (or both new and old
according to my scheme)?
I.e. I was thinking that first of all, we have a period where old zone
content (including NS) will be cached all over the place. During this
time period, we have both old and new DS at parent, and we keep both
old and new DS in parent for a while. As long as we think anyone have
old NS cached.
Problem exists of course if people either only have old DS and follow
new NS, or new DS and follow old NS.
If the validating resolver then refetch the DS (and get both old and
new from parent, as a normal key rollover), then we are ok, right?
I think the best way to get this working is if we can make sure that
a validator will go back to the parent to verify if NS and DS
records have changed once validation fails. Search for a changed
chain of trust.
Agree is this good.
If we cannot mandate that to resolvers/validators, then the
procedures for changing DNS-operator (and thus registrar,
registrant, etc) will become very complex, and can only be done with
the cooperation of the losing DNS-operator if you don't want outage.
The loosing DNS operator then needs to sign the DNSKEY records from
the gaining DNS operator with his private key, and publish those
RRsigs.
Not fun. Not possible I would say.
I would like best not to have complex procedures. So can we mandate
resolver/validation behavior ?
Since when? ;-)
I see problems today where someone (me) have A and AAAA for a
nameserver. If that nameserver is not reachable over IPv6 (I only have
one such nameserver unfortunately) the resolvers seems to not fall
back to IPv4 as transport of the DNS queries. I.e. the NS have both A
and AAAA, but only AAAA is tried. Not fun.
Patrik
Antoin Verschuren
Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands
P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970
mailto:antoin.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl
http://www.sidn.nl/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
