On Tue, Jun 30, 2009 at 12:43:35PM +0200, Patrik Fältström wrote: > >> 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.
That's a task for the registrar. > 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)? Yes, the referral should be accompanied by the DS RR and a new RRSet should drive the old one out of the cache. An identical would, but probably should not, extend the TTL of the cached copy. > >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. I do not think NS RRs should ever explicitly asked for. In addition, I also don't believe that the resolver or validator should derive any conclusions from a new or changed NS RRSet - except that new data might replace old data. However, the parent's servers may not be in sync and I wonder whether this approach wouldn't lead to a DDoS on the parent's servers without careful throttling of the re-queries. > 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. It depends on how multiple A or AAAA RRs are treated. If a server is dead (doesn't respond over v6) I see no reason not to try the next server until you get a response. -Peter _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
