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

[Paul Wouters <[e-mail]>]

On Mon, 4 Mar 2019, Christopher Morrow wrote:

>               "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.
> 
> 
> this wasn't, near as I could tell, an option for the ccTLD in question.
> They lost their IP access, and were 'required' to disable their dns zone, their master was down hard from the internet's perspective,
> keeping anything else up wasn't really an option.

We should not base our DNS domains on scenarios where a DNS administrator
loses access to all their IP addresses and therefor could not operate
the DNS as required.

> i think it prolongs the data being available in a bunch of the cases I can imagine/have-seen.
> I think there's at least one case where it's likely grave harm could have come to the dns operator. :(

Grave harm beyond being already completely disconnected from the
internet? I think that kind of harm is not something we can address
in protocol design.

> I think what the draft does is attempt to guess at WHY a thing is changed, without an real data to back up the reasoning. this will mean the decision is wrong
> more than a small percent of the time.

You will have to provide a few scenarions that we can actually evaluate
to back that statement. To me, if your presence has been basically cut
from the internet, then this is no longer an internet protocol issue.

>       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.
> 
> 
> sometimes that's not possible :( and the expectation is that 'when the right ttl sets expire all of our records disappear as you requested"

If your servers are connected to the internet, that remains the case.
The case we seem to talk about is only when all authoritative servers
are down. If you get non-technical pressure to bring things down without
getting TTL extensions, explain to those cutting you of that they can
get a shorter disconnect time by letting you run a modified DNS
configuration on your servers?

>       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 is also not always possible :(

Sorry, again you have to substantiate your answer here. Make up an
imaginary story to illustrate this if you cannot use a real example.

>
>       I don't think the "4 years" is a realistic problem case.
> 
> is the '4 years' here in reference to the .eg problem?

I have no idea what the ".eg problem" is.

> in my example the '4 yrs' was: "when the incident happened" not "please keep my dns alive for 4 yrs without talking to me"

Ahh.

>       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.
> 
> 
> seems unlikely to be useful... even in the case of dos...really.
> (to me anyway)

If I need a few hours up to a few days to try and work around a DDOS
attack by adding capacity or some external provider to help me deal
with the DDOS, then buying those few hours are what is keeping a domain
online during such an attack. So while that might not apply to you, it
is an actual real use case.

Paul