Dangling AAAA Record detected

The Security Center reports a “Dangling AAAA Record” for my account. This explains why in webserver failure logs only IPv4 addresses can be seen (I have no general access logs enabled). Strange is that a CNAME record for a sub domain, used for SSH/SFTP access, which bypasses the Cloudflare proxy, works just well with IPv6, using it to trigger a webserver error as well as with SSH/SFTP connections works well and the client’s IPv6 address is shown in the log. Of course I tripple checked that the IPv6 address is correct, and it can even be used plain (instead of hostname) to connect to the server.

So it seems that Cloudflare has issues connecting/verifying the IPv6/AAAA record while it does actually work pretty well. Any ideas how to debug this?

Practically it is not an issue since IPv6 clients can of course still connect, only Cloudflare connects strictly via IPv4 to the origin, as of the issue, I assume.

Just to confirm, I’m seeing this myself as well. I just had a look at Security Center » Security Insights. I see multiple “Dangling AAAA record detected” listed.

However, those AAAA records are correct. And, IPv6 connections that I’ve manually tested are working for the hostnames listed there.

Good to know that I’m not the only one. If this was a visual issue only, I wouldn’t be so bad, as one can archive and that way hide the warning. But since it seem to cause Cloudflare to always connect via IPv4 to the origin, it is a larger issue, I’d say.

Still so many reasons why IPv6 won’t become the mandatory future of the Internet any time soon :smile:.

I’m not sure why the erroneous errors are being shown for valid AAAA records in Security Center. Generally though, when both IPv4 and IPv6 connections are available, Cloudflare prefers IPv4.

Is that so? That would contradict the behaviour of everything else (every browser, client, command line tool etc I know prefers IPv6 by default) and basically it means that IPv4 is always used since there are no (or nearly no) hosts with AAAA record only. Also it contradicts what Cloudflare states on the settings why one cannot disable IPv6 anymore:

At Cloudflare we believe in being good to the Internet and good to our customers. By moving on from the legacy world of IPv4-only to the modern-day world where IPv4 and IPv6 are treated equally, we believe we are doing exactly that. In the Cloudflare dashboard, IPv6 is no longer something you can toggle on and off, it’s always just on.

Of course client access to Cloudflare and Cloudflare access to origin are two different things, but it breaks the argument when IPv6 is forcefully enabled for clients while it is practically never used by Cloudflare itself to connect to the backend. And I guess the IP family switch can also cause issues with some applications, facing a mismatch between what the backend gets and what the frontend sends. So the only reasonable behaviour would be to always prefer keeping the IP family which the client uses already, and only change it if the backend does really not support what the client uses.

Within the Cloudflare dashboard, at Network » IPv6 Compatibility » Help, you’ll also see this:

When both IPv4 and IPv6 connections are available, Cloudflare prefers IPv4.

1 Like

Ah, I haven’t seen this one. Surprising, this doesn’t make much sense to me, but Cloudflare should know better than me :smile:.

Okay, so then indeed we cannot know whether the dangling AAAA record warning breaks IPv6 connections to the server or not, unless we disable the A record, which cannot be done on our public production host to not break connections for the still large share of IPv4-only clients/visitors.

I get the “dangling AAAA record” too. I have no idea what it’s on about. The AAAA records are correct and work.

One of them has only an AAAA record for the origin, so all traffic from Cloudflare to the origin is over ipv6 and it works.

1 Like

Okay then it’s the security center test only, which reports the dangling record falsely.

If IPv4 is preferred anyway by Cloudflare, then I wonder what the purpose of an additional AAAA record is, since it remains unused (when Cloudflare proxy is used).
EDIT: Ah no, of course it is still required for clients to connect via IPv6 (to Cloudflare).
EDIT2: Again no, no AAAA record is required for clients to connect via IPv6, so the question whether an AAAA record has any point remains valid.
I’ll ask that matter in a separate topic.

I’ve just submitted a ticket (#2410215) to Cloudflare asking about this issue.

Hi guys,

From our internal documentation:

Security Insight / Detection Method / What it might lead to

Dangling ‘AAAA’ Record detected - We have detected other hostnames that resolve to this IP address. The server accepts HTTP or HTTPS connections and does not respond to your hostname that points to this IP address. - An attacker may gain control of your domain’s infrastructure and redirect traffic intended for your domain.

Please do contact the product Team via email if you would like better messaging. More feedback means more resources and importance placed on the Product’s improvement.

Thank you.

What a dangling AAAA record means is clear and the docs about it fine, it is just falsely evaluated by the security centre. I can just speak for me, but I guess it is the same in all above cases: Our servers accept HTTP and HTTPS connections and they DO respond to the hostname and IP address and no attacker gained control of it. I’ll also try to open a ticket about it.
EDIT: I sent an email to the Security Center team.

1 Like

The emails seem to have helped. I didn’t get a reply, but today the dangling AAAA record in our Security Center has gone :tada:. Can you guys verify the same in your cases?

The warnings are gone from my Security Insights.

While they were gone yesterday, I just had a look, and they’re back again now. :man_shrugging:

Same here :confused:.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.