In message <list-17781...@execdsl.com>, =?WINDOWS-1252?Q?Patrik_F=E4ltstr=F6m?=
writes:
> On 30 jun 2009, at 12.02, Antoin Verschuren wrote:
>
> > So let's not discuss the mixing up of roles like registrar, =20
> > 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 =20
> > operator, in 90% of the cases they don't.
> >
> > The problem is in any transaction that involves a dns-operator =20
> > change for the zone.
> > Since this is a DNS discussion, let's not discuss registrars, =20
> > registrants, etc.
> > I only want to know how to move a DNSSEC zone from one DNS operator =20=
>
> > to another one, without outage.
>
> Agree.
>
> > I don=92t agree with you here:
> >
> >> We have a problem when "a domain changes hands" and the private DS =20=
>
> >> 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 =20
> > the truth are still accepted by DNS resolvers.
> > As long as you make sure the same data is in the old and new zone =20
> > (except for the NS set), the general public doesn't notice anyting.
> > In the period between the delegation change at the parent and the =20
> > 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 =20
> > one validates), leading to a partial blackout for those resolvers/=20
> > 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 =20=
>
> client have cached the old DS, while following the new NS, then there =20=
>
> 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 =20=
>
> 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 =20
> > caches.
> > That's the real issue.
>
> I agree with this, but is it not the case that you only(!) get this =20
> problem if the NS and DS are timing out at different points in time? =20
> And you have a cached DS, while looking up a new NS from parent zone? =20=
>
> And if you do, do you not get the new DS as well (or both new and old =20=
>
> according to my scheme)?
>
> I.e. I was thinking that first of all, we have a period where old zone =20=
>
> content (including NS) will be cached all over the place. During this =20=
>
> time period, we have both old and new DS at parent, and we keep both =20
> old and new DS in parent for a while. As long as we think anyone have =20=
>
> old NS cached.
>
> Problem exists of course if people either only have old DS and follow =20=
>
> new NS, or new DS and follow old NS.
>
> If the validating resolver then refetch the DS (and get both old and =20
> new from parent, as a normal key rollover), then we are ok, right?
Validators shouldn't have to refetch DS records to work
around a broken key rollover.
This is simultaneous roll of KSK and ZSK keys. You introduce
the keys the *same* way as you would with a single operator.
The new operator generates new keys. The are added to the
existing DNSKEY RRset and the resulting RRset is signed by
all the KSKs (old and new). DS are added to the parent for
then new KSKs. Wait for the pre-change DS and DNSKEYs to
expire from caches. You use the new ZSK keys to sign the
zone content. If you are changing servers as well you make
the the old servers serve the new zone content. Once all
the old zone content has timed out of caches you remove the
old keys. If you changed servers this is the time to
decommision the zone on the old servers.
> > I think the best way to get this working is if we can make sure that =20=
>
> > a validator will go back to the parent to verify if NS and DS =20
> > records have changed once validation fails. Search for a changed =20
> > chain of trust.
>
> Agree is this good.
Can you say DoS attack?
> > If we cannot mandate that to resolvers/validators, then the =20
> > procedures for changing DNS-operator (and thus registrar, =20
> > registrant, etc) will become very complex, and can only be done with =20=
> > 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 =20=
> > the gaining DNS operator with his private key, and publish those =20
> > RRsigs.
>
> Not fun. Not possible I would say.
Can we stop giving up before we have tried to make this work properly?
If we say it can't work then no one will try. If we say it can work
and expect it to work then it will work.
Publish a BCP on how to do this. Seller and buyers alike can
offer/request BCP compliance. Failure to follow BCP is not likely
to a seller if they end up in court for deliberately damaging the
property they are selling. It's like you trashing a house as you
move out if you fail to follow the BCP.
> > I would like best not to have complex procedures. So can we mandate =20=
>
> > resolver/validation behavior ?
>
> Since when? ;-)
>
> I see problems today where someone (me) have A and AAAA for a =20
> nameserver. If that nameserver is not reachable over IPv6 (I only have =20=
> one such nameserver unfortunately) the resolvers seems to not fall =20
> back to IPv4 as transport of the DNS queries. I.e. the NS have both A =20=
>
> and AAAA, but only AAAA is tried. Not fun.
That's a broken iterative resolver. AAAA vs A is no different
to two A's or two AAAA's. You should try both today as you
know the will be path failure that make one unreachable but
not the other. On the otherhand if you have a bad answer
returned over IPv6 there is no reason to expect a good
answer over IPv4 as both nominally refer to the same machine.
Mark
> 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/
> >
> >
> >
>
>
> #############################################################
> This message is sent to you because you are subscribed to
> the mailing list <dnssec-deploym...@shinkuro.com>.
> To unsubscribe, E-mail to: <dnssec-deployment-...@shinkuro.com>
> A public archive is available here: <http://mail.shinkuro.com:8100/List=
> s/dnssec-deployment/>
> and older material is at
> <http://mail.shinkuro.com:8100/Lists/dnssec-deployment-archive/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
