In message <a4dc1d4d-3cc5-4bb7-a724-72bebd0ea...@virtualized.org>, David Conrad writes: > On Sep 10, 2009, at 12:36 PM, Edward Lewis wrote: > >>> Still, what it is attempting to do is within limits. > >> And within the limits of local policy, that's fine. What is simply > >> broken > >> is having that local policy have global impact. > > > > The local policy of "trusting DLV" is not having a global impact, > > just a local impact on the parties relying on the cache with that > > policy. > > Again, I am not objecting to people using DLV. I think it is ucky, but > that's just me. What I am objecting to is the suggestion made here > that _before a TLD that has submitted its keys to the ITAR rolls its > keys, it must notify the (potentially multiple?) folks who run a DLV > registry, of which the TLD may have no knowledge, who have harvested > ITAR data and wait_. That's just crazy talk.
ITAR is supposed to being used by people to configure trust anchors for TLDs until the root is signed. There will always be a lag between when data is entered into ITAR and when it is turned into trust-anchors. Whether it is updating named.conf directly or DLV there will be a lag. PR waited way too long to add the record to ITAR. It should have done it immediately after it published the DNSKEY. There is not point in waiting once the DNSKEY is published. Instead PR waited 2 weeks then added the record to ITAR. PR then waited 2 day and hoped that everyone would have seen the ITAR change and updated their configuration and pulled the record. Now when ITAR goes away and the root is signed then the timing would have been reasonable but not perfect as the timing would normally have allowed the old DS RRset with only the old DNSKEY reference in it to flush from the system. To be perfect you need to wait <parent expire> + <ds ttl> so that stealth parent servers that are out of contact with their masters have expired the zone and any records they served have also flushed from caches. We need the EDNS EXPIRE option I proposed so the these timings can be made deterministic rather than hope that there isn't a loop in the axfr transfer graph which keeps a zone alive indefinitely. Mark > >> There are multiple DNSSEC testbeds. Are you making use of them? > > No - none have been appropriate for what we would want to test. > > What do you want to test? > > Regards, > -drc > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
