-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Marc,
As you said, there is already text in 4641bis on this subject. There is text that provides guidelines on TTLs for DS records: ..., there is the TTL value on the DS RRs. Shortening the TTL reduces the damage of a successful replay attack. It does mean that the authoritative servers will see more queries. But on the other hand, a short TTL lowers the persistence of DS RRsets in caches thereby increasing the speed with which updated DS RRsets propagate through the DNS. And section 4.4.1 covers many time considerations. Although not explicitly about NS RRset, imho they do cover all the considerations related to DNSSEC operational practices. So to be clear, I don't think the document needs to address this topic to more extent. Best regards, Matthijs On 04/02/2012 01:53 PM, Marc Lampo wrote: > Hello, > > Following up on last week's DNSOP gathering in Paris, where one > contribution pleaded for long TTL's (on infrastructure records) and > another for short TTL's. > >> From the humming results I interpret that consensus will be hard >> to reach. > Would it be an idea to spend some words on the theme in RFC4641bis > ? (there is already wording in that draft, linking short TTL to > applying corrections) As that document does not "give strong > recommendations", but mostly "guidelines" (quoted from the > Introduction of that draft), no "consensus" is needed and > guidelines can refer to security aspect. > > However : the authors of the draft on long TTL's showed data on a > large set of domains, over a period of time; regarding changes to > NS records. Since they can already provide a table with % of > changes over a period of time, can you also provide data on TTL of > "about to be changed records" ? In other words : For those domains > where a NS change was noticed, do you also have data on TTL values > of the records, prior to the change ? (I assume most did not reduce > the TTL of the old data) --> I remember a statement of 75% that did > not change NS records. Leaving 25% that did change. If the change > was not preceded by a lowering of TTL before the change, that 25% > is the percentage of domains that will be *negatively* affected by > large TTL's on infrastructure RR's ! > > > Kind regards, > > > Marc Lampo Security Officer EURid (for .eu) > > _______________________________________________ DNSOP mailing list > [email protected] https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPebiQAAoJEA8yVCPsQCW5uJYIAJIepLp5HokBhOLXYWu3317w c9LZz+G7uFEK+rjihoUAH4qB3VoCTALlWL43BFkjuCq/kc+7lsTZCsh5U4mCrpRL X3cypOeVL3QKvtpIMBTEsCuuMqD2swqu99wOF4zXZqqNLc5BzFL020Ok/37cyI1V XYoL64xuh0m+0D2/AihKDdHftmCgzEBEcrjUpzX/lYGZH3hQEvypbIyKt1XwMBEB SA5JUzQL5Z3xnxc5+15ACzrUKuu0MM12gthLutgLtr3JSVy86kx3eoAh6oBsm2EG MtZ2ZK5RPKV1Mwf+8krNIiqu39QsojvIwhUBd9dH9wFkmH/lfTJMA0dVWsUaDmA= =PXB3 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
