On Tue, 5 Mar 2019, Paul Hoffman wrote:
On Mar 5, 2019, at 7:59 AM, Dave Lawrence <t...@dd.org> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
