After switching my domain’s name servers to Cloudflare’s, I’ve run into a problem that seems fairly common. Lots of people asking about it and not any good answers.
I have 2 specific subdomains setup, ipv4.domain.com and ipv6.domain.com. The DNS record for ipv4.domain.com points to an ipv4 destination address. The record for ipv6.domain.com points only to an ipv6 destination address.
A connection originating from an ipv4 source could not connect to ipv6.domain.com, for example.
Doing an nslookup on each subdomain now shows they share both ipv4 and v6 name servers from Cloudflare.
It seems Cloudflare registers both ipv4 and ipv6 name servers for every subdomain/domain registered in their internal DNS settings.
Depending on a user’s connection, if that connection only supports ipv4 and connects, the originating v4 address is passed through.
If the connection supports v4 and v6, it will preferentially use the v6 name server and the connection’s v6 address gets passed through to the server, regardless of the DNS settings configured inside of Cloudflare.
Having the two separate subdomains and their functions is an important part of my product. I’m at a bit of a loss to see if there’s a way to correct this inside of Cloudflare.
Moving the two subdomains back to a different set of name servers would remove the DDoS protection Cloudflare provides, obviating the reason for enabling it in the first place.
Any suggestions?
Hi there,
Unfortunately I don’t believe this is possible, at least without a workaround on an Enterprise plan.
You do have the ability to disable IPv4, but it’s localised to a specific zone (domain.com for example) and adding a subdomain as a zone is only available to Enterprise customers.
There is some more help here:
This also details “Pseudo IPv4” which will send a fake IPv4 address for your IPv6 clients, but still doesn’t resolve the overall problem you have.
I’m having exactly the issue this person reported back in November last year: https://community.cloudflare.com/t/cloudflare-proxy-create-only-one-record/433279/11
There didn’t seem to be a satisfactory resolution to their issue when they reported it either.
Cloudflare should respect the DNS records that the user is setting. If I only set an A record for a subdomain, then an AAAA record should not be added automatically. Same for the other way around, too.
In the previous report I linked to, towards the end of the conversation they talk about disabling the proxy on the subdomain in question. However, doing that completely throws out the reason for using Cloudflare in the first place.
In my case, my service has been getting a massive DDoS on one specific ipv4.domain.com subdomain for weeks. I enabled Cloudflare a few days ago to help mitigate that problem. If I disable the proxy for that subdomain, then all of that DDoS traffic just flows right back to my servers again.
For my product, I absolutely have to be able to reliably get an accurate ipv4 address on requests to that subdomain. Not a pseudo one generated by Cloudflare. My users have different use cases. In cases where a connection has both ipv4 and ipv6 addresses available, my users can choose one of those two subdomains (ipv4/ipv6) to get either/or IP address. If they don’t care, they just get the ipv6 one from domain.com directly.
I would eagerly pay to upgrade to the Pro plan to have an option to fix this dns issue, or to have some other work around with Cloudflare. I was completely floored the other day after enabling CF and watching all of the stats on my servers level out for the first time in weeks and immediately go back to normal. I really want to give you guys money, but the gap between $20 Pro and $250 Business is pretty much a no-go, at least for me.
Any other ideas on how to work around this problem?
I’m curious what you are trying to do?
This has nothing to do with whether or not the nameservers are accessible over IPv6 or not.
You can disable the automatic IPv6 support using the API.
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/<zone_id>/settings/ipv6" \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
--data '{"value":"off"}'
The two subdomains are a feature of the api that I run, https://jsonip.com.
There are lots of users who want to get their ipv4 address instead of ipv6. For years I have had this working quite well over at Linode. I created an A record for ipv4 and AAAA record for ipv6. VM’s at Linode have both v4 and v6 public addresses. I’m not entirely sure how Linode does the routing internally, but depending on which subdomain a visitor hits I reliably get the v4 or v6 address in x-forwarded-for.
Unfortunately some shmuck has been DDoSing the ipv4 subdomain for the last month. I finally had to give in and enable Cloudflare. Really, really amazing product. Just having an issue with this IP thing.
Yeah, I’m starting to lean that way. I know my way around the basic every day setup stuff with domains and DNS, but this more advanced nameserver stuff is pretty new to me. I realized today that I had the wrong idea about what was happening yesterday and was convinced it had to do with an ipv6 name server, which doesn’t make sense really now that I know a little more.
Unfortunately I can’t do that. I’m currently running on the free plan, and would happily upgrade to Pro but beyond that. $250 a month or enterprise is way beyond expensive for what should more or less be a basic feature. It appears you can only disable ipv6 on an entire zone. Only enterprise accounts can add subdomains as zones. So either way, that’s not something I’m able to do.
I could turn the proxy off for the ipv4 subdomain, but that just obviates using Cloudflare at all. Since that’s the subdomain that’s still being targeted, all that traffic would just flow directly back to the server.
In a bit of a pickle here and not seeing any viable options.
Your use case is similar to the Cloudflare operated domain of icanhazip.com which also has an ipv4 and ipv6 only subdomain. I have a site that returns IP an user-agent details and needs IPv4 and IPv6 exclusive hostnames for the same reason. It’s a blocker for moving that domain’s DNS to Cloudflare. I don’t have an answer, but I share your interest in this particular edge case.