It does seem like it would be good to document the "Authoritative Forwarding
Proxy" use-case as it is more common. There are a number of commercial
services doing this now, both for performance, DDoS defense, and other
use-cases.
An important thing we really should define is safeguards for loop
prevention (eg, an EDNS0 hop-count limit or something like rfc8586 which
defines CDN-Loop). Doing this without Loop Prevention is dangerous, at
least based on experience with similar patterns in the CDN world. Even if
we don't define the broader specification, I'd be very interested in seeing
standardization of loop prevention in both recursive and authoritative
forwarding setups.
There's lots of work that would be needed on this draft (I'm not sure that
the way TTLs are handled is the only way we might want to define, as there
may be other approaches). Similarly, it may make sense to allow ECS under
certain circumstances (for example, if DoT or DoQ is used from the
forwarding proxy to the origin authoritative).
Erik
On Wed, Oct 18, 2023 at 5:13 PM Philip Homburg <[email protected]>
wrote:
> 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
