[DNSOP] a CDN perspective on ANAME challenges
Erik Nygren <erik@nygren.org> Fri, 12 July 2019 17:52 UTC
Return-Path: <nygren@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719A31205F6 for <dnsop@ietfa.amsl.com>; Fri, 12 Jul 2019 10:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.163
X-Spam-Level:
X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkTA3KNYXcc9 for <dnsop@ietfa.amsl.com>; Fri, 12 Jul 2019 10:52:18 -0700 (PDT)
Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CFF120602 for <dnsop@ietf.org>; Fri, 12 Jul 2019 10:52:17 -0700 (PDT)
Received: by mail-wm1-f47.google.com with SMTP id l2so9708027wmg.0 for <dnsop@ietf.org>; Fri, 12 Jul 2019 10:52:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PSDnzCmjUt53/ehAz2IDDygNoSvjrOBzQheEYqdipHI=; b=jWtxqIabPr+qdD9qQT4iuO4krNEPjcW37RrrgcVoJ7wbXgDBAfHqGv2pUJ6pSrlT4Z GC2N/vZP7iJQiQujhMOYJTombHBBF8gBdB+vFTeyPzYDcGUghc7tKEN+grnXKmWHh8Re 96kyzXPObCNlAbnnGZJH+kaHryHNzxL6UbP/B/T73vtQu1isAKvaID7M19yFqubenI87 RyZRoSqhU41gS8pEimXunNRS3n7rZhPL1lgz5bGTSoU7QcA6RjGFqNsrkGW7esxc5v7Q MwrBbE7ynCcGSk3w9A60QhH0p7rUDNmbSSncrr7Y4/N1LvGEC8NHHxT5qivYeQ882iN+ wNHg==
X-Gm-Message-State: APjAAAW8BVPhAwWFQ3fsAV0qrb10lI0irsCeBDVmJWVyFmkwh/znVCi4 7zdl6S6mXj+f4KJIn5cwVKpoQxhWy0JC8/F/sSvDjWp4ucQ=
X-Google-Smtp-Source: APXvYqzOfS1r8oSys+Bl79CPwofNyybT7I1Bfv3eos4oGlWAHMdEbudj+ww/Dh+rVcCKH4My9krDVvAj8BRloZQoG18=
X-Received: by 2002:a05:600c:34a:: with SMTP id u10mr10143140wmd.43.1562953934046; Fri, 12 Jul 2019 10:52:14 -0700 (PDT)
MIME-Version: 1.0
From: Erik Nygren <erik@nygren.org>
Date: Fri, 12 Jul 2019 13:52:02 -0400
Message-ID: <CAKC-DJjiwEA977sLpriPg5yyfm--yCQ=xMUGk7VbXyYd8uPE6g@mail.gmail.com>
To: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000a0a0f058d7f9210"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KZbv9GJx5eSluy1cTj4qID2wWrE>
Subject: [DNSOP] a CDN perspective on ANAME challenges
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 17:52:23 -0000
One of the intended goals of ANAME is to improve interoperability of onboarding onto CDNs for URLs at a zone apex, such as “http(s)://example.com ”. The TL;DR is that ANAME is unlikely to allow interoperability here unless authorities are willing to effectively and scalablely do recursion-with-ECS for all requests (caching keyed by ECS prefix and obeying short, sub-minute TTLs). Simply resolving “sibling address records” on a zone master (per draft-ietf-dnsop-aname-04) is likely to be declared incompatible and unsupported (or at least severely restricted) by at least some (if not many) CDNs. For some background, Dan York highlights some sample use-cases here: https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01 For example, web publishers want to do the equivalent of: example.com 300 IN CNAME a123qk.example-cdn.net. Two use-cases (quoted from draft-york above): 1. users will be able to simply enter "example.com" into their browser; and 2. users will only see "example.com" in their address bar (if URLs are even displayed). Note that for some CDNs, the “a123qk.example-cdn.net” target name dynamically selects which IP addresses to return based on a wide variety of factors (recursive nameserver IP, end-user IP prefix passed via ECS, dynamic load and liveness conditions, product, customer security requirements, TLS certificate needed for non-SNI-only configurations, etc) and often have short TTLs (often in the range of 20s to 60s, although sometimes up to 300s). Some CDNs have had vertically-integrated solutions for onboarding zone apex names for years, allowing example.com to hand back CDN IPs as long as the zone is delegated to the CDN authorities. The need for these to be vertically integrated comes from the level of complexity involved in calculating these answers. Even these vertically integrated solutions may have limitations. For example, one early vertically-integrated solution had very similar functionality to some of the ANAME proposals. It only covered case #1 above, handing out a subset of CDN IPs (with limited performance). Along with this was a correlated site HTTP configuration that would issue a 30[127] redirect to “www.example.com” which would in-turn use a normal set of CDN IPs. This doesn’t help for the “users will only see ‘example.com’ in their address bar” case due to the need to redirect to a hostname that can fully CNAME. More advanced vertically-integrated solutions that can also handle case #2 may involve high-volume feeds of proprietary dynamic state and configuration being fed to the authoritative nameservers, allowing them to construct answers on-the-fly. It is unclear if third-party authoritative servers will be able to do enough here to be compatible with CDNs, at least until we get to a point where most/all recursive servers support ANAME sibling address substitution (and there are huge numbers of these around the world run by a huge variety of operators!). For third-party authoritative servers wishing to collapse A/AAAA names into a zone as signalled by an ANAME, some of the options include: 1. Primary zone master does sibling address substitution: Some CDNs will declare this to be strictly incompatible. (ie, all traffic would be directed to a small set of IPs associated with where the Primary Master is located). This would defeat the purpose of using a non-purely-anycast CDN. 2. Zone secondaries do frequent sibling address substitution: Some CDNs may still declare this to be incompatible. Traffic is still directed to a small subset of IPs associated with where the zone secondaries are located. If the zone secondaries are widely deployed, some CDNs might be able to support this using anycast configurations, although that might limit to a subset of products or limit to a subset of CDN server locations and might have CDN SLA limitations. 3. Authoritative resolvers do a mixture of the following, which is likely what would be needed to be compatible with CDNs that do DNS-based traffic direction: - Online / on-demand lookups using ECS, with response caching. (Possibly requiring collaboration with the CDN to be on an ECS ACL or allowlist.) - Online DNSSEC signing. - Honoring short (eg, 20s-60s) response TTLs. - Having the scale/capacity and attack resilience to be able to support this possibly-low-cache-hit-rate request workload. It is only the third of these that might actually work well enough, but may add a huge amount of complexity to authorities, requiring the authority to also have many recursive functionality. It is possible that some authoritative operators are willing and able to do this to enable interoperability. However, if this set of functionality is what is required to make ANAME work well enough to achieve its goals, then we should be clear on that. It would be a mistake to go through all of the effort of rolling out ANAME only to find that CDNs declare it to be incompatible. I’ll add the caveat that the HTTPSSVC proposal doesn’t fully or magically solve this problem either. It is likely that A/AAAA records will need to live at the zone apex for a long time to come. If those are static addresses, they’ll likely still need to do 30[127]-style redirects to “ www.example.com” names. However HTTPSSVC leaves an option for “example.com” requests (eg, those containing an Alt-Used request header) to not need to return a redirect, allowing a somewhat more graceful transition as client adoption picks up. Erik
- [DNSOP] a CDN perspective on ANAME challenges Erik Nygren
- Re: [DNSOP] a CDN perspective on ANAME challenges Mark Andrews
- Re: [DNSOP] a CDN perspective on ANAME challenges Matthijs Mekking
- Re: [DNSOP] a CDN perspective on ANAME challenges Erik Nygren
- Re: [DNSOP] a CDN perspective on ANAME challenges Matthijs Mekking
- Re: [DNSOP] a CDN perspective on ANAME challenges Ben Schwartz
- Re: [DNSOP] a CDN perspective on ANAME challenges Matthijs Mekking