Per-Entity Metadata Working Group

["Cantor, Scott" <>]

On 7/27/16, 2:12 PM, 
"
 on behalf of Jorj Bauer" 
<
 on behalf of 
>
 wrote:

> The records themselves have a TTL. Caching servers can cache the data
> until that TTL expires. After that, no - there's no guarantee the data 
> would be useful, and it's flushed.

Right, but AFAIK it's typically cached in memory by the processes that are 
performing requests, or *maybe* by the kernel. If you reboot, and the DNS is 
down, you're dead in the water, as well as if you query something for the 
first time that day.

> With the beginning of MDQ, I think this architecture would be desirable
> until we have mature infrastructures.

Thanks, that makes much more sense to me in context.

But I think you would agree that the world today is a bit different from what 
it was when DNS was getting real. Back then your Unix wizard ran the network 
and he was happy to set up fancy stuff to compensate for the crazy new flaky 
DNS thing.

I think this would be a hard sell now.

>    Apologies for having missed the background, and maybe asking something 
>    that's obvious to everyone else at this point - I have a standing 
>    meeting at the time of the weekly calls, unfortunately - but is there 
>    any sort of TTL on metadata served by MDQ? As an endpoint, I'd want to 
>    know how long it is viable for. Which enables various sorts of caching.

Metadata has a cacheDuration coupled with local settings around how 
aggressively to pre-fetch, and a separate hard validUntil to prevent the 
attacks that stale metadata can open up.

Of course HTTP caching can also be in play, but I think MDQ is designed 
around avoiding the need to couple these layers.

-- Scott