[dns-operations] EC2 resolver changing TTL on DNS answers?

[Giovane C. M. Moura]

thanks everybody again for sharing your thoughts.

So I decided to take a look and how often does DNS TTL violations happen
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!
That may put users at risk of service domains that  may have been
already taken down.

/giovane



On 12/01/2017 03:18 AM, Ángel wrote:
> On 2017-11-29 at 07:43 -0800, Colm MacCárthaigh wrote:
> 
> 
>>         i'd like to think that hierarchical autonomy would mean that
>>         i, as a zone publisher, would be in sole control of how long
>>         my data is cached. if rdns operators want to negotiate, by
>>         protocol, over longer leases, then by all means let's make
>>         that possible.
>>
>>
>> I think on balance, I would still prefer if every resolver served from
>> stale cache when auth DNS becomes unreachable, rather than return
>> SERVFAIL, at least for a few hours. You're right that that means a
>> domain that's being taken down may persist, but if we can take down
>> the DNS servers, is taking down the web servers (or whatever) ...
>> really harder or more complex? 
> 
> The ability to take down a dns server is orthogonal to the ability of
> taking down a web server hosted there.
> But yes, although it can be easier, it could be much harder.
> 
> 
> Also note, it is much easier to detect a dns-provider takedown than a
> hosting takedown. In the later case, they could easily be providing a
> fake "website blocked" banner, while still serving their clients
> (victims).
> 
> 
> I agree however that serving stale data (for a limited time) when the
> authoritative server is unreachable would be beneficial.
> 
> 
> Best regards
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>