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

[Paul Wouters <[e-mail]>]

On Tue, 5 Mar 2019, Paul Hoffman wrote:

> On Mar 5, 2019, at 7:59 AM, Dave Lawrence <[e-mail]> wrote:
>>
>> Paul Wouters writes:
>>> 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 ?
>>
>> I personally have a very strong opposition to including servfail.
>> Servfail is an extremely clear indication that the authority that was
>> contacted is having some sort of structural problem.  It is a very
>> distinct condition from being told by the authority that the name does
>> or does not exist.
>
> I agree with David on this. This has been clear since RFC 1035.

I am a bit confused here. The goal of the draft is to keep data past the
TTL in case you cannot reach the authoritative servers during a DDOS
attack.

If you reach the authoritiatve server, and it gives ServFail, you did
reach the server. You might have "structural problems" but not in the
way of a denial of service attack. Unless you are saying DNS
implementations that are overloaded return ServFail instead of dropping
the packets?

Misconfiguring your authoritative server by removing the zone is not
meant to be covered by this draft if I understood it correctly. If it
is, then introduction will need to add text to cover that use case.

Paul