Re: TTL on DS records

Patrik Fältström <[email protected]> Sat, 21 Feb 2015 12:15:29 +0100
Newsgroups gmane.ietf.dnsext
Message-ID <[email protected]>
--===============2358554017533118275==
Content-Type: multipart/signed;
 boundary="Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE";
 protocol="application/pgp-signature"; micalg=pgp-sha1


--Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On 21 feb 2015, at 11:50, Patrik Wallstr=F6m <[email protected]> wrote:
>=20
> On 21/02/15 02:19, Wessels, Duane wrote:
>> Section 5 of RFC 4034 says:
>>=20
>>   The DS RR has no special TTL requirements.
>>=20
>> While RFC 4035 Section 2.4 says:
>>=20
>>   The TTL of a DS RRset SHOULD match the TTL of the delegating NS =
RRset
>>=20
>> Due the "SHOULD" I'm not sure this is worthy of an errata, but seems =
rather unfortunate.
>>=20
>> Apologies if this is a previously known issue.
> Several TLD operators have a lower TTL on the DS. The reason is to =
help
> the registrant to recover from a signature failure and be fast to =
remove
> the DS. I think this is one of the reasons to why there is a SHOULD =
there.

My personal view is that the TTL for the DS should be really short. I.e. =
much shorter than what people might think. This because any kind of key =
rollover (when doing transfer etc) or forwarding of private keys, or any =
other "correct" theoretical model of how to do transfer in reality I =
think is just...theory. Specifically as one of the main reasons for =
doing transfer is that the loosing registrar/dns operator is that they =
do not do their job. And because of that have double reasons for not =
cooperating in the transfer.

But, I would like some really smart people think about what "really =
short" should be. 15 minutes?

   Patrik


--Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFU6GjRrMabGguI180RAp3nAKCGCu0jgAu8DIusMPxG79uV7MvaagCeN0fc
uGr1FH0PBEW94xUDEuEh5Y8=
=7ZlH
-----END PGP SIGNATURE-----

--Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE--


--===============2358554017533118275==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext

--===============2358554017533118275==--