Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

[Paul Wouters <[e-mail]>]

On Tue, 5 Mar 2019, Mark Andrews 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.

 	"If the recursive server is unable to contact the
          authoritative servers for a query "

So make the DNS server reachable, but return ServFail or NXDOMAIN. If
the owner doesn't cooperate and there is legal standing, talk to the
parent to do this for the delegation.

I don't think this draft stops a domain from being brought down
intentionally.

>> 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" ?

The DNS resolvers who want to accomodate their governments need to
manually override their resolvers anyway with new (forged) data. This
draft does not change that.

If the owner itself wants to bring the domain down, they just need to
make its auth servers reachable.

If the DNS hoster wants to bring it down, they just need to modify the
data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records.

>> 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.

I don't really follow this reasoning. Are you saying that:
1) if the domain owner wants their domain to be reachable
2) and they have lost their auth servers due to a DDOS attack
3) they might prefer to be down over extending the TTL a bit

In the non-DDOS case, the auth server is reachable and none of the data
is getting additional TTL added:

    Answers from authoritative servers that have a DNS Response Code of
    either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have
    refreshed the data at the resolver.  In particular, this means that
    this method is not meant to protect against operator error at the
    authoritative server that turns a name that is intended to be valid
    into one that is non-existent, because there is no way for a resolver
    to know intent.

Although perhaps it should also explicitely state this regarding
ServFail ?

> 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.

See above. It seems a bit overkill for a strange corner case. But even
so, one could specify the maximum ever allowed TTL to be like 3 days? Which
I think is kind of enforced by most DNS resolvers anyway?

Adding more TTLs would just make this more complicated and more error
prone and not lead to reduced outage times which is the goal of this
draft.

I don't think the "4 years" is a realistic problem case.

I can see how people want to get a few hours or a few days of usage
beyond the TTL to accomodate for errors. Although, it is likely that
moving up the error this way will also delay the error from being
detected before the extra time has expired, and we are just moving
the goal post with no effective gain. But in the case of a DDOS
attack, the draft's feature is surely useful.

Paul