Re: TTL on DS records

--===============5914297705754651413==
Content-Type: multipart/signed;
 boundary="Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E";
 protocol="application/pgp-signature"; micalg=pgp-sha1


--Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 21 feb 2015, at 13:21, Andrew Sullivan <[email protected]> =
wrote:
>=20
> On Sat, Feb 21, 2015 at 12:15:29PM +0100, Patrik F=C3=A4ltstr=C3=B6m =
wrote:
>>=20
>> My personal view is that the TTL for the DS should be really short.
>=20
> This would be yet another reason for people not to turn on validation,
> because validating will become an excellent way to increase latency in
> page loading.  It seems to me that you want to defend against one
> problem (lousy operator) by creating a new one (poor caching).  I'm
> not convinced that's an excellent trade off.

Well, my point is that there is a balance, and I ask for a calculation =
of that balance.

Today, with a lousy operator that one move a domain away from have a =
delay in effect of that move which is based on the TTL of the DS.

My question is how long we think that delay should be, to not affect =
caching too much.

Given we see caching issues anyway around the net that question why we =
have 48h TTL on some records.

I am not after 1 second TTL, but maybe it should be recommended to be 1h =
and not 48h.

I also btw do see complaints on registries only updating their zone =
every 4h or 8h, so I see a clear trend to have shorter caching.

I was just after a discussion :-)

   Patrik


--Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E
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

iD8DBQFU6JCqrMabGguI180RArn6AJoCNRnvG9LG0fnBt0xKSU+RKIBGcwCfcpBK
R7XhyPPTu5lsGVplFCSyXqs=
=HVov
-----END PGP SIGNATURE-----

--Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E--


--===============5914297705754651413==
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

--===============5914297705754651413==--