Subject: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

From: bert hubert <[email-masked]>
Date: Sun, 21 Sep 2014 13:52:22 +0200

Hi everybody,

Your input on the initial implementation described below would be most
appreciated.  I see this as a dns operations issue since it does not
describe an on-the wire change, except when we do AXFR perhaps.  It is
mostly a feature.

However, even features could have interoperability issues, and it would be
nice if we were aligned.

The last forwared paragraph below says "Please let us know your thoughts
based on the semantics outlined above.  Would this work for you?  Do you
miss anything?  Is there a need for multiple ALIAS statements for load
balancing?  Are we needlessly incompatible with existing implementations? 
Is there standardization work we could align against?"

Thanks!

	Bert

----- Forwarded message from bert hubert <[email-masked]> -----

Date: Sun, 21 Sep 2014 12:54:07 +0200
From: bert hubert <[email-masked]>
To: [email-masked]
Subject: [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

Hi everybody,

Based on strong user interest, we are fast-tracking the implementation of
ALIAS/ANAME records, to solve the 'CNAME at apex' problem. Because of the
fast-tracking, we need rapid feedback to see if we got it right (see the end
of the mail for details).

In short, you can CNAME 'www.yourdomain.com' to a CDN or somewhere else, but
you can't CNAME 'yourdomain.com', since that breaks DNS. This blogpost by
CloudFlare expands on the problem:
https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root

Today, we implemented ALIAS support as an experimental PowerDNS feature,
which allows the following:

$ORIGIN example.com.
@       IN      SOA     ns1 ahu 2014091619 7200 3600 1209600 3600
@       IN      NS      ns1
@       IN      NS      ns2
www     IN      CNAME   xs.powerdns.com.
ns1     IN      A       1.2.3.4
ns2     IN      A       4.3.2.1
@       IN      ALIAS   www.powerdns.com.
@       IN      MX      25 outpost.ds9a.nl.
elsewhere       IN      CNAME   @

The branch can be found on https://github.com/PowerDNS/pdns/tree/alias and
we should have packages soon. 

The current semantics for the ALIAS pseudo-record are that they only match
if no real record did.  So in the case above, an MX query for example.com
would return "25 outpost.ds9a.nl".  But a query for AAAA would return the
IPv6 address obtained by following the www.powerdns.com CNAME chain to
xs.powerdns.com. This also works for all other record types, btw.

Our implementation uses a defined resolver to look up the actually requested
record, and adds the data found to the packet built so far. This means that
querying 'elsewhere.example.com' will include a CNAME to example.com, which
in turn will lead to processing of the ALIAS record.

Finally, for TTL, we currently use what the resolver gave us. But perhaps we
could use the TTL of the ALIAS record instead, or as a maximum? Or minimum?

Please let us know your thoughts based on the semantics outlined above.
Would this work for you? Do you miss anything? Is there a need for multiple
ALIAS statements for load balancing? Are we needlessly incompatible with
existing implementations? Is there standardization work we could align
against?

Your input is highly welcome!

	Bert

PS: the above is currently not yet supported for DNSSEC domains!

-- 
PowerDNS Website: http://www.powerdns.com/
Contact us by phone on +31-15-7850372

_______________________________________________
Pdns-users mailing list
[email-masked]
http://mailman.powerdns.com/mailman/listinfo/pdns-users

----- End forwarded message -----

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Sep 2014 08:13:46 -0700

Two questions (although other folks are likely to have more questions).

> xs.powerdns.com. This also works for all other record types, btw.

- What happens / should happen if the "@  IN MX 25 outpost.ds9a.nl." record is not in the zone file and the server gets an MX query for example.com?

> PS: the above is currently not yet supported for DNSSEC domains!

Can you say (much) more about that aside? Does it mean that the server will fail to load the zone if there is DNSSEC records and ALIAS pseudo-records? Or that the DNSSEC gets broken? Or that the ALIAS gets broken? Or... ?

--Paul Hoffman

---

From: bert hubert <[email-masked]>
Date: Sun, 21 Sep 2014 20:14:34 +0200

> - What happens / should happen if the "@  IN MX 25 outpost.ds9a.nl." record is not in the zone file and the server gets an MX query for example.com?

It proxies that on as an MX query for www.powerdns.com and puts back the
answer. So ALIAS is type transparent.

> Can you say (much) more about that aside? Does it mean that the server
> will fail to load the zone if there is DNSSEC records and ALIAS
> pseudo-records?  Or that the DNSSEC gets broken?  Or that the ALIAS gets
> broken?  Or...  ?

In the current branch, it will load the zone, but neglect to add signatures
for the proxied records. In other words, if you do DNSSEC, it will load the
zone but make you BOGUS. 

This is not a fundamental problem as long as we have keys. If you don't have
the keys, we can't sign any how. We'll add the signing code shortly, we just
haven't typed it in yet.

An interesting opening is that we'd be signing potentially unsigned data
this way. Potentially, we should check for the AD bit. But first let's see
how this idea fits.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Sun, 21 Sep 2014 11:37:28 -0700

> bert hubert <mailto:[email-masked]>
> Sunday, September 21, 2014 4:52 AM
> ...
>
i'd be very interested in a standards-track (interoperable; including
DNSSEC support and AXFR/IXFR) version of this feature. my hope is that
you will remove out-of-zone capability here, that is, the target of
ALIAS should have to be authority data in the same zone. this would
simplify the DNSSEC case, but more importantly, it would avoid having
authority servers make upstream queries.

if you decide to work on this, i'll contribute as at least a reviewer
and perhaps (if invited) as an editor.

-- 
Paul Vixie

---

From: Dick Franks <[email-masked]>
Date: Sun, 21 Sep 2014 19:49:43 +0100

On 21 September 2014 19:14, bert hubert <[email-masked]> wrote:

> Must validate the response. Otherwise bad actor can just toss in a bogus
AD bit!

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 21 Sep 2014 16:14:51 -0400

Hi,

This topic has come up here many times before, and there always seems to be interest. A fielded implementation and Paul's suggestion of an interoperable spec both seem like healthy developments.

Suzanne

On Sep 21, 2014, at 2:37 PM, Paul Vixie <[email-masked]> wrote:

> 
> 
>> 	bert hubert	Sunday, September 21, 2014 4:52 AM
>> ...
>> 
> i'd be very interested in a standards-track (interoperable; including DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you will remove out-of-zone capability here, that is, the target of ALIAS should have to be authority data in the same zone. this would simplify the DNSSEC case, but more importantly, it would avoid having authority servers make upstream queries.
> 
> if you decide to work on this, i'll contribute as at least a reviewer and perhaps (if invited) as an editor.
> 
> -- 
> Paul Vixie
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Doug Barton <[email-masked]>
Date: Sun, 21 Sep 2014 14:04:26 -0700

On 9/21/14 1:14 PM, Suzanne Woolf wrote:
> Hi,
>
> This topic has come up here many times before, and there always seems to
> be interest. A fielded implementation and Paul's suggestion of an
> interoperable spec both seem like healthy developments.

As always I stand ready to revive 
https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if 
there is interest.

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 21 Sep 2014 14:06:04 -0700

On 9/21/14 2:04 PM, Doug Barton wrote:
| On 9/21/14 1:14 PM, Suzanne Woolf wrote:
|> Hi,
|>
|> This topic has come up here many times before, and there always
|> seems to be interest. A fielded implementation and Paul's
|> suggestion of an interoperable spec both seem like healthy
|> developments.
|
| As always I stand ready to revive
| https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit
| if there is interest.

I should add that I'll be at the DNS-OARC and ICANN meetings here in
LA in October if anyone wants to discuss the issue.

Doug

---

From: David Conrad <[email-masked]>
Date: Sun, 21 Sep 2014 14:10:59 -0700

On Sep 21, 2014, at 2:04 PM, Doug Barton <[email-masked]> wrote:
>> This topic has come up here many times before,

And like the joke about the weather...

>> and there always seems to
>> be interest. A fielded implementation

There are at least three implementations of ‘alias mechanism for zone apex’ I’m aware of (DNS Made Easy’s ANAME, PowerDNS’s ANAME (same thing?), and CloudFlare’s “CNAME Flattening”). Not sure if they interoperable (or even if there is a need for interoperability).

>> and Paul's suggestion of an
> As always I stand ready to revive https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if there is interest.

Given the end of the DNSEXT working group, perhaps there is sufficient interest to have a BOF (Bar, Beach, or otherwise) in Honolulu?

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Sun, 21 Sep 2014 14:23:03 -0700

> David Conrad <mailto:[email-masked]>
> Sunday, September 21, 2014 2:10 PM
> ...
>
> There are at least three implementations of 'alias mechanism for zone apex' I'm aware of (DNS Made Easy's ANAME, PowerDNS's ANAME (same thing?), and CloudFlare's "CNAME Flattening"). Not sure if they interoperable (or even if there is a need for interoperability).

from the point of view of many operators and implementers (so, like dns
made easy, powerdns, and cloudflare from your example above) there is
almost certainly a disadvantage to interoperability and standardization
here, that being economic, in that as long as this feature remains
incompatible, a single vendor is likely to gain business via "lock in".
my reason for preferring a standardized way to do this is to make it
possible for a registrant to get primary name service from one vendor
and secondary name service from one or more others vendors.

i don't think it makes sense to question, inside the IETF, whether a
vendor-independent interoperable standard is desirable. we can ask
questions of the form "but is this good engineering?" or "is this the
best way to do it?" or even "what should the applicability statement
be?" but since the IETF's stated purpose is to promote interoperable
standards, if we want to argue about whether we need an interoperable
standard for this widely-used feature, we should move that thread to a
non-IETF forum where it would not be a nonsequitur.

-- 
Paul Vixie

---

From: David Conrad <[email-masked]>
Date: Sun, 21 Sep 2014 15:30:00 -0700

Paul,

On Sep 21, 2014, at 2:23 PM, Paul Vixie <[email-masked]> wrote:
>> (or even if there is a need for interoperability)
> i don't think it makes sense to question, inside the IETF, whether a vendor-independent interoperable standard is desirable.

Who said anything about desirability?

The reason for my parenthetical was that in at least one implementation, the existence of the ‘alias mechanism for zone apex’ is never externally visible, so the question of whether or not that implementation is interoperable would be moot.

Regards,
-drc

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 21 Sep 2014 15:33:16 -0700

On Sun, Sep 21, 2014 at 11:37 AM, Paul Vixie <[email-masked]> wrote:

> DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you
> will remove out-of-zone capability here, that is, the target of ALIAS
> should have to be authority data in the same zone.
>

But then the feature is pointless; you could just include the record
directly at the apex if you knew what the value should be.

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Sun, 21 Sep 2014 15:52:13 -0700

> Colm MacCárthaigh <mailto:[email-masked]>
> Sunday, September 21, 2014 3:33 PM
>
>
>     i'd be very interested in a standards-track (interoperable;
>     including DNSSEC support and AXFR/IXFR) version of this feature.
>     my hope is that you will remove out-of-zone capability here, that
>     is, the target of ALIAS should have to be authority data in the
>     same zone.
>
>
you make a good point. i'm curious about the implication.

does the ANAME(/ALIAS) server proxy every request, so, no caching? or,
if it caches, does it implement "client subnet"? and, either way: if the
proxied request times out (or servfails), does the original authority
request also time out (or servfail?) and i wonder-- if the proxy request
returns NXDOMAIN, what does the authority answer with?

what the implementers of this nonstandard feature seem to want is
cname-and-other-data, by which i mean, a requester-visible alias that
can live at the apex, and then have its target resolved in the
requester's context. i'm not sure how best to do it, but i'm not liking
the implications of always-proxy nor proxy-with-cache.

-- 
Paul Vixie

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 21 Sep 2014 19:22:49 -0400

> There are at least three implementations of ‘alias mechanism for zone apex’ I’m aware of (DNS Made Easy’s ANAME, PowerDNS’s ANAME (same thing?), and CloudFlare’s “CNAME Flattening”). Not sure if th…

I'm personally fine with a discussion here of whether an interoperable standard is worth the effort, likely to be adopted, etc. 

Previous versions of this discussion have included use cases where interoperability is part of the value of an alias feature-- for example, if I'm a domain owner who wants both to determine the behavior of an "alias" in terms of what a client sees and to have flexibility across managed-DNS providers, I want a standard to hold my vendors to.

> Given the end of the DNSEXT working group, perhaps there is sufficient interest to have a BOF (Bar, Beach, or otherwise) in Honolulu?

As a first cut, the general topic is IMO on charter for the WG, if people seriously want to work on this.

I like David's idea of an informal BOF. I'm not sure of logistical constraints for the venue in Honolulu but I'm happy to work on pulling something together. 

Descriptions of the workings of the known "alias" features currently in the world would be helpful inputs, along with any specific use cases or problem statements people have in mind. The goal would be to get a preliminary idea of whether there's useful work to be done on the subject within the IETF process, beyond periodic bull sessions on the list, and if so, what's the most effective way to proceed.

best,
Suzanne

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Sep 2014 10:42:32 +0100

bert hubert <[email-masked]> wrote:
> if no real record did.

Why not restrict it to A and AAAA?

I forsee problems with zones that have MX and ALIAS at the apex which
accidentally get the wrong SPF record, for example.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Sep 2014 11:03:37 +0100

I can see roughly three ways this might be done, in order of increasing
complexity...

(1) Master-only. The master observes an ANAME record at the apex of a zone
it loads and uses it to periodically refresh the relevant records in the
zone (as if you had a cron job running dig | magic | nsupdate).

Disadvantage: potentially lots of XFR traffic if the TTLs are low.

(2) Authority-only: All authority servers recognize ANAME records,
PowerDNS style.

Disadvantage: all authority servers need DNSSEC private keys.

(3) DNAME-style: Authority servers and resolvers recognize ANAME records.
ANAME-aware servers (auth and rec) return the synthesized records for
backwards compatibility, without signatures. For DNSSEC purposes the
signed ANAME goes in the answer section and the original signed target
goes in the additional section.

Disadvantages: forklift upgrade; DNSSEC codepoint rollover.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Sep 2014 11:05:50 +0100

Doug Barton <[email-masked]> wrote:
>
> https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit

I am confused by the use "label" in that document. Do you really mean a
single component of a domain name wherever you say "label"?

Tony.

---

From: "John Levine" <[email-masked]>
Date: 22 Sep 2014 11:12:14 -0000

>zone (as if you had a cron job running dig | magic | nsupdate).

I have implemented something like this, with master file syntax

foo IN A [rmtip:bar.remote]

The implementation fetches any A and AAAA records from bar.remote and
invents local A and AAAA records.  It rechecks every hour or so.

>Disadvantage: potentially lots of XFR traffic if the TTLs are low.

My crock manages the zone serial numbers and only changes the serial
number and does a notify if the zone changes.  It's all done in python
scripts on top of NSD.  It doesn't do DNSSEC yet but I don't see any
problems since the zones that NSD sees are ordinary zones.

I agree that Paul's suggestion to limit this to references within the
zone would make it useless in practice unless it also resolved CNAMEs,
which turns it back into the more complicated case.

R's,
John

---

From: Dick Franks <[email-masked]>
Date: Mon, 22 Sep 2014 12:20:45 +0100

On 22 September 2014 11:03, Tony Finch <[email-masked]> wrote:

> Why would TTL be relevant here?

Is the master not acting as a "partial slave" for the target RRs?
In which case, the timing should depend on the SOA refresh period.

No reason to do XFR.  Each (assuming these to be plural) ANAME target could
be resolved independently.

Rs
Dick

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Sep 2014 12:27:33 +0100

> In which case, the timing should depend on the SOA refresh period.

Yes, you could do it that way. But a lot of people want changes to take
effect quickly.

And I forgot to cover the effects that client-subnet might have ...

Tony.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Sep 2014 09:21:31 -0400

On Sun, Sep 21, 2014 at 03:52:13PM -0700, Paul Vixie wrote:

> does the ANAME(/ALIAS) server proxy every request, so, no caching? 

Some people have tried to implement it that way.  This is an excellent
way to DoS your server, it turns out (rumour has it that someone
learned that in production; but if you make a fairly simple
performance model you can derive this result on paper).

> if it caches, does it implement "client subnet"? 

It sort of has to, not that it will necessarily be useful.  An
important use case is CDNs, and since you probably want to do stupid
DNS tricks based on the source of the query, you better do client
subnet with it.  (Of course, statistically speaking right now that
means, "Works for Google and OpenDNS and not really anyone else.")

> returns NXDOMAIN, what does the authority answer with?

There are use cases where the "right" answer is to extend the cache
value you had, even though the TTL has expired.  In other cases, you
should just pass on whatever you got, so you're working like a cache.

> the implications of always-proxy nor proxy-with-cache.

Yes.  For what it's worth, at Dyn we've come up with four different
designs for this functionality, every one of which has some compromise
that has caused my product people to say, "No, not like that."  I am
increasingly convinced that this feature is one of those well-known
ponies.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dick Franks <[email-masked]>
Date: Mon, 22 Sep 2014 14:27:14 +0100

On 22 September 2014 12:27, Tony Finch <[email-masked]> wrote:

> So whenever TTL times out, master does validated lookup of each ANAME
target, resigns, updates zone, notifies own slaves, services XFRs.

Someone beyond your direct control sets a short TTL (0 or 1) in ANAME
target RRs and your master is in deep, deep [trouble] !!

Thinking about it, (target side) SOA refresh is not much better.

>  I do not know either

Rs
Dick

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Sep 2014 06:57:59 -0700

> for the proxied records. In other words, if you do DNSSEC, it will load the

Far be it from me to tell you want to do with your UI, but that seems like a worse choice than refusing to load the zone and giving an error that indicates that the zone file is misconfigured. In specific, when the operator will discover that the zone is bogus because someone else tell them, they will stare at the zone file and see nothing wrong.

> the keys, we can't sign any how. We'll add the signing code shortly, we just

I'm not sure what that paragraph means at all.

> this way. Potentially, we should check for the AD bit. But first let's see

It is seeming to fit, so discussing the DNSSEC implications of it seems appropriate to do now.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Mon, 22 Sep 2014 15:06:02 +0100

> means, "Works for Google and OpenDNS and not really anyone else.")

The fun bit is that an auth server implementing some kind of proxying
ANAME is in a position very like Google and OpenDNS. That is, if the
target of the ANAME is a hostname provided by Akamai or CloudFlare or
whoever, and if the auth server is going to proxy the answer faithfully,
then it has to implement client-subnet.

Tony.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 22 Sep 2014 07:41:32 -0700

> then it has to implement client-subnet.

I wonder if the best thing to do would be to define an ANAME/AAAANAME
that can be negotiated by resolvers. If the resolver supports it (it
can let the auth know via EDNS0) then the ANAME/AAAANAME is returned
without resolution. If the resolver doesn't support it, then a
synthetic A/AAAA can be returned.

-- 
Colm

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 22 Sep 2014 13:37:03 -0400

I’m getting confused about what the exact semantics of the proposed mechanisms are. 

Q1: The intent is that  ALIAS/ANAME/etc are a fallback rewrite operation if the name does not have the type asked for?

Q2: Is there a good  reason to restrict this to just the apex of a zone? 

Q3: Is there a  good reason to restrict the target of A* to be in-zone ? 

Q4: Is there a  good reason to restrict this to specific types? (Think about DANE cases with names like _443._tcp.@apex) 

> Disadvantage: potentially lots of XFR traffic if the TTLs are low.

Disadvantage: if the target is a CNAME what does the master do? 
It either need to know ALL possible types that may exist or use NSECx record to determine what exists. 
Possible disadvantage: Master/master signer needs access to resolver to access out of zone-data. 

Further disadvantage: if the A* target is out of zone at a CDN then the answers the “master” gets back reflect its 
location. 

> Disadvantage: all authority servers need DNSSEC private keys.

Not an absolute requirement, we could play type code tricks that allow master server to store 
A* target records as different types but servers know that to check for them if A* exists. 
Disadvantage: All authority serves supporting A* need to know about type translation and signers need to know to perform actions. 

> Disadvantages: forklift upgrade; DNSSEC codepoint rollover.

You mean DNSKEY alg code points,? 
We only have 5 popular algorithms so that is not a big deal?

	Olafur

---

From: bert hubert <[email-masked]>
Date: Mon, 22 Sep 2014 20:09:01 +0200

> I’m getting confused about what the exact semantics of the proposed mechanisms are. 

We're here to figure those out. Thanks for your input Olafur, appreciated!

> Q1: The intent is that  ALIAS/ANAME/etc are a fallback rewrite operation if the name does not have the type asked for?

The intent is to solve the 'CNAME at apex'-problem. The implementation needs
to keep SOA, NS etc alive, but override at least A and AAAA. Hence the
fallback, to retain SOA and NS.

> Q2: Is there a good  reason to restrict this to just the apex of a zone? 

No, and it isn't implemented like that right now.

> Q3: Is there a  good reason to restrict the target of A* to be in-zone ? 

No, since the specific use-case is to hand off to a CDN name, which is
unlikely to be in-zone.

> Q4: Is there a  good reason to restrict this to specific types? (Think about DANE cases with names like _443._tcp.@apex) 

I think Tony's input that you might end up with an incompatible SPF
if you fall-through for MX makes a good case to restrict to 'address
records', currently A and AAAA.

The open questions are: what to do on an ANY query? You can't proxy on an
ANY query to auth as an ANY query to a resolver since the semantics are
different. ANY queries are fragile enough as is, but to maintain any
semblance of working, an ANY query hitting an ALIAS type should be proxied
on as an A and an AAAA query, and both should be tacked on to the answer.

	Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 22 Sep 2014 21:15:48 +0200

Based on the discussions here (thanks!), I've now written this up as:

https://github.com/PowerDNS/pdns/blob/alias/pdns/docs/alias.md

The ALIAS record
The ALIAS record leads authoritative servers to synthesize A or AAAA records
in case these are not present. The source of the synthesized A or AAAA
record is specified by the target of the ALIAS record.

etc..

Feedback welcome! I note that there has been discussion on EDNS0 probing and
other fancy things, but please note that this feature is needed to solve a
problem we have today. This means it can't involve upgrades to
infrastructure except for that operated by the people with the problem -
authoritative servers.

	Bert

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Sep 2014 18:19:14 -0400 (EDT)

> infrastructure except for that operated by the people with the problem -

If we can do this with auth only changes in a sane way, I'm all for it.

But if a decent solution requires recursor updates, we should not leave
that solution space out of scope.

A bandaid for those that need this today is to delegate the A record of the
apex and the www record to the CDN, and MX, NS and SRV records to their
own infrastructure. And to refrain from using the apex A/AAAA for any other
service.

Paul