Error 1016 with authorative CF nameservers

I have the domain mahlberg.io with Cloudflare as authorative nameservers for the whole domain:

So no subdomain delegation etc.

The RRs are either created manually, or - in the case of the system in question - by external-dns, a Kubernetes service that watches ingress resources for external hostnames and provisions them with various DNS providers, in my case CF.

With the system in question, auth.mahlberg.io this worked for a couple of hours. The host is located on a Digital Ocean cluster in Frankfurt, Germany. Since another couple of hours, this host is either unresolvable or CF returns the error 1016. Even 1.1.1.1 does not resolve the host,

although it is properly provisioned according to the dashboard:

Another Kubernetes service, support.mahlberg.io provisioned the very same way (down to the same origin IP), seems to works flawlessly.

Since I thought it could have something to do with the TTL, I increased it for the RR (zone abbreviated by me):

time="2020-03-29T11:21:25Z" level=info msg="Changing record." action=UPDATE record=traefik.mahlberg.io targets=1 ttl=1 type=A zone=2ed...
time="2020-03-29T11:21:25Z" level=info msg="Changing record." action=UPDATE record=auth.mahlberg.io targets=1 ttl=180 type=A zone=2ed...
time="2020-03-29T11:21:26Z" level=info msg="Changing record." action=UPDATE record=support.mahlberg.io targets=1 ttl=1 type=A zone=2ed...
time="2020-03-29T11:21:27Z" level=info msg="Changing record." action=UPDATE record=traefik.mahlberg.io targets=1 ttl=1 type=TXT zone=2ed...
time="2020-03-29T11:21:30Z" level=info msg="Changing record." action=UPDATE record=auth.mahlberg.io targets=1 ttl=1 type=TXT zone=2ed...
time="2020-03-29T11:21:31Z" level=info msg="Changing record." action=UPDATE record=support.mahlberg.io targets=1 ttl=1 type=TXT zone=2ed...

However, as you can see, the TTL is not reflected in the dashboard (this might be a different problem).

Please note that DNSSec is aktivated for the domain. However, I am the administrator of another domain (undisclosable), and a similar problem exists without DNSSec being activated and the Kubernetes cluster being on private hardware, with a totally different registrar.

So I have several questions:

  1. How can it be that the RR is properly provisioned, while both authorative NS as well as the CF resolver return an error in resolving the hostname?
  2. Why are the TTL settings ignored with API access?
  3. I have read that some people deactivate the proxy function of cloudflare for the respective hosts. While being a short term measure, this can hardly be a long term solution. What measures can be taken to have a reliable DNS resolution?

EDIT: I can confirm that as soon as I deactivate proxying, the name is properly resolved.

I though it might have soomething to do with a missing in-addr.arpa for the IP in question, however, it is resolvable:

It’s resolving for me at 1.1.1.1. Can you post the result of this:
dig +short CHAOS TXT id.server @1.1.1.1