Re: [DNSOP] Measuring DNS TTL Violations in the wild

Ólafur Guðmundsson <olafur@cloudflare.com> Fri, 01 December 2017 16:38 UTC

Return-Path: <olafur@cloudflare.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0FA127286 for <dnsop@ietfa.amsl.com>; Fri, 1 Dec 2017 08:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmgZvZMI15h1 for <dnsop@ietfa.amsl.com>; Fri, 1 Dec 2017 08:38:09 -0800 (PST)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86389126DCA for <DNSOP@ietf.org>; Fri, 1 Dec 2017 08:38:09 -0800 (PST)
Received: by mail-wr0-x22e.google.com with SMTP id y21so10707080wrc.1 for <DNSOP@ietf.org>; Fri, 01 Dec 2017 08:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iiIlr+dPzcxNkYLYqDU4QFTIIEH4fvns74PI6KopilM=; b=KKZts07GeL7cNbmz2wKEL8t+NIt0Y+HHiczAPwRHoZcNGnkK/xAPX04GxJgLCnOzM4 rWpP+mSVFp02tYbecYBNEP44K9zlcoLmGpraZXj7hbNYDs/LubaV0qndHUmqUhorkf2N 14zHJ/X2gCtf8ADFPHHWG3xHnrjpNaJo7QNaA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iiIlr+dPzcxNkYLYqDU4QFTIIEH4fvns74PI6KopilM=; b=lhrkfAKplE7ic9VTmfuQb+AG15HglGRXxZiZvEW9c5ducNIZEkZGbgIA8NR7npGgkI Bq94IN+d/vAHZIB5RFAzbQvr8JtD0r/MluJZfHTKrLUroq7GDwld82SXcg0bkj6QEV3+ OUuNHErFMHwbxsTSXlj7orzDEmY+Dijgs8LAZye9PkGNUw/gYPl1WXBdFI2hP4fdf/tl epngbk9GQcjGN7gWzZrm0zvxV/GwS9XaXAeJLz6WwO5OHaBoFfphwqHBZcyhYylJvpTy cOI2gTWtmE0577/dUy/eAOv2PkkwX7mX5qxBgsO4ize4V8MUP9iEp1BrmHvft4xOr4fT fqNw==
X-Gm-Message-State: AJaThX5xh2zBDcoZ531BCNA5i3Zd7bkHQIWUg8hOXqnEgX/WkPjQ5D/z /Uv19k7l5OGU6CAY9Rzi1BuDWSMqpK9RqEuD7BQzb8M7
X-Google-Smtp-Source: AGs4zMaaDfkSzNAGiDC23mObcfYm1QleiCoXOOhwAeAS7lfqTbK0ykNxGd+Ylm5nJoKAyFzathwoHO3AwTqDvzyeojo=
X-Received: by 10.223.132.101 with SMTP id 92mr6143541wrf.85.1512146287793; Fri, 01 Dec 2017 08:38:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.166.136 with HTTP; Fri, 1 Dec 2017 08:38:07 -0800 (PST)
In-Reply-To: <aec2510c-e543-6c4a-873d-5c2db7df5a78@sidn.nl>
References: <aec2510c-e543-6c4a-873d-5c2db7df5a78@sidn.nl>
From: Ólafur Guðmundsson <olafur@cloudflare.com>
Date: Fri, 01 Dec 2017 16:38:07 +0000
Message-ID: <CAN6NTqytiDj-FfixD6aKD4AKa5oik7SEtP=82JhP4GR=SyWjYw@mail.gmail.com>
To: "Giovane C. M. Moura" <giovane.moura@sidn.nl>
Cc: dnsop <DNSOP@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0d21085533f0055f49fee2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fwz9TUIk8LARdIPyoqnLD2k84LQ>
Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Dec 2017 16:38:12 -0000

I strongly disagree with your "terminology", TTL is a hint about maximum
caching period, not a demand or a contract.
A resolver can at any time for any reason discard cached entries.
Many Authoritative operators have "unreasonable" TTL's like less than 10
seconds or multiple days and I see no reason why resolvers do not
apply minimal and/or max caching rules that are reasonable.

Olafur




On Fri, Dec 1, 2017 at 3:48 PM, Giovane C. M. Moura <giovane.moura@sidn.nl>
wrote:

> Hi,
>
> In the light of the recent discussions on TTL violations and server
> stale here on the list, I decided to take a look on how often resolvers
> perform TTL violations in the wild.
>
> To do that, I used almost 10K Ripe Atlas probes. You can find a report
> and datasets at:
>
> https://labs.ripe.net/Members/giovane_moura/dns-ttl-
> violations-in-the-wild-with-ripe-atlas-2
>
> Now, what was more scary were the violations that *increased* the TTL of
>  of RR some more than 10x. That may put users at risk of service domains
> that may have been already taken down.
>
> /giovane
>
> ps: related thread on oarc list at :
> https://lists.dns-oarc.net/pipermail/dns-operations/2017-
> November/017039.html
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>