> On 5 Mar 2019, at 1:26 pm, Paul Vixie <[email protected]> wrote:
>
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
>> can I ask, what happens when a domain is intentionally down though? For
>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
>> master/shadow NS go down, hard. All public auth servers eventually (in a
>> day or so) went dark too.
>
> i already raised that question, very far up-thread. got no answer.
>
>> If someone is 'ordered' to make a zone dark, there may be reasons for that
>> action, and real penalties if the request is not honored.
>> Is this draft suggesting that the DNS operations folk go against the wishes
>> of the domain owner by keeping a domain alive after the auth servers have
>> become unreachable? How would a recursive resolver know that the auth is
>> down: "By mistake" vs: "By design" ?
>
> this the essence of the argument against utility for this entire proposal. no
> data should be served beyond its TTL unless some new leasing protocol is
> first
> defined, to obtain permission and to provide a cache invalidation method.
>
> vixie
And one can to that if we add 2 TTLs to each DNS record. One for total time to
live and one for freshness (old client get this). It will require EDNS to
signal
that multiple TTLs are desired and are present in the response and may require
using the last DNS flag bit to move the OPT record to in front of the question
section to make parsing easier (no trial and error).
Yes, this is radical but it will work and is incrementally deployable.
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
