On 14. 11. 25 9:34, Philip Homburg wrote:
In BIND itself SERVFAIL cache has 1 second TTL and keyed by (class,
qname, qtype). Consequently, a typical web browser query for
(portal.internal.example.com A+AAAA+HTTPS) will cause 6 outgoing
queries to the auth, 6 cache SERVFAIL entries for 1 second, rinse
and repeat until I close the browser tab I forgotten about.
It seems that the fundamental problem here is that we don't have a TTL for
SERVFAIL.
I agree!
If the upstream resolver has support for 'NS .' then it could report the
TTL of the NS record as the TTL of the SERVFAIL.
Forwarders could use the TTL of the SERVFAIL they get from upstream instead
of a hard coded value.
There are plenty of DNSSEC failures that are not going away soon. No need to
keep trying every second.
Adding a TTL to SERVFAIL will take time but maybe in the future it will
allow us to use SERVFAIL (or other error codes) as a more useful signal
that something is really not there and that the situation is not expected
to change any time soon.
I agree this would be useful protocol work, albeit long-term. Until we
have that I think "NS ." will do more harm than good.
I'll leave out the encoding of the SERVFAIL, I'm sure we can come up with
something.
Encoding is 'easy enough'. Problem is security as this information is
not a RRset so it cannot be protected by DNSSEC.
But perhaps in the brave new world of ubiquitous DoH/3 (:trollface:) we
can just trust whatever the remote sends? (:trollface: :trollface:)
More seriously:
Perhaps for scenarios where client trusts the remote end to do recursion
and takes answers from it at their face value (typical for global
forwarding) then perhaps it would make sense.
Too bad we don't have threat model written down anywhere for forwarding
scenario... Or do we? Is there a document I have missed?
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
