Hi Philip,
I don't really want to discourage you, but I think this is in general a
bad idea: optimizing for the best case, but no benefit -- or even
twice(?) as more resources consumption -- under a random-subdomain attack.
It looks even weirder to me when I see you argumenting with DDoS
protection in the draft Introduction.
However, Erik indicated that some commercial services are already doing
this, so I might be wrong in considering it a bad idea (or might not).
Regarding the ECS stuff, I guess that if this is implemented, it should
you the exact same tricks for sharing ECS among authoritative servers as
with full AXFR/IXFR. Unfortunately, those tricks are not yet defined by
IETF (which we suffer as well). I think this deserves some BoF as soon
as the DNS community gets less busy with current stuff. But this is a
broader idea which is partly orthogonal to yours.
Libor
Dne 18. 10. 23 v 17:13 Philip Homburg napsal(a):
Based on some feedback we received, I created a draft that describes what to
do if you want to build a proxy that acts as an authoritative server in an
anycast setup. The draft just describes the basics, if there is interest we
can add the details.
Name: draft-homburg-dnsop-igadp
Revision: 00
Title: Implementation Guidelines for Authoritative DNS Proxies
Date: 2023-10-17
Group: Individual Submission
Pages: 5
URL: https://www.ietf.org/archive/id/draft-homburg-dnsop-igadp-00.txt
Status: https://datatracker.ietf.org/doc/draft-homburg-dnsop-igadp/
HTML: https://www.ietf.org/archive/id/draft-homburg-dnsop-igadp-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-homburg-dnsop-igadp
Abstract:
In some situations it be can attractive to have an authoritative DNS
server that does not have a local copy of the zone or zones that it
serves. In particular in anycast operations, it is sensible to have
a great geographical and topological diversity. However, sometimes
the expected use of a particular site does not warrant the cost of
keeping local copies of the zones. This can be the case if a zone is
very large or if the anycast cluster serves many zones from which
only a few are expected to receive significant traffic. In these
cases it can be useful to have a proxy serve some or all of the
zones. The proxy would not have a local copy of the zones it serves,
instead it forwards request to another server that is authoritative
for the zone. The proxy may have a cache. This document describes
the details of such proxies.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop