.AU Domain adding to Cloudflare

Good news is it looks like we had a 6:00AM AEDT sync both Saturday and Sunday.

1 Like

100% - that blog post by kyle-k is correct and VentraIP are doing what they can.

What an absolute bollocks-up by Afilias.

Its simply incredible that these things are done manually. Gods, it reminds me of 1995 and dealing with Richard at Pre-MelbourneIT. Jesus I hate MelbIT. Can’t believe they still exist.

1 Like

Yeah absolutely craziness that this was something that was a considered a viable option.

If they needed more time they could’ve just taken more time given the DNSSEC issue from a day two before launch I think people would’ve been okay if it was postponed.

However to be honest they would’ve been better off doing a soft launch.

Thankfully before my time.

Yeah but the good news is the people that bought them the commercial business side of what remained of Melbourne IT Group, 5G Networks seem to be doing pretty good at cleaning up years of mess and neglect a lot better than CentralNic you have really balls up and taking their sweet arse time cleaning up TPP Wholesale.

It is still broken, and it’s pretty random if Cloudflare will accept a .au 2LD.

I’ve had an enterprise support ticket open for a few days now, but it appears to be stalled in the first level support (rather than escalating it to someone who can FIX the problem, they offered to add it manually… Sigh)

1 Like

This issue is now resolved. Zone file syncing is now automated again. Name Server update should propagate immediately and not require a sync event to happen.


That’s not the problem. The problem is EVEN WITH a sync’ed zone, Cloudflare are randomly saying ‘this is not a registered domain’. I’ve got a couple of example zones in my Support Ticket that they can use to check that.

However, SOME Zones are working fine. I suspect there’s some caching happening, and some magic needs to happen to invalidate the ‘not registered domain’ cache (which had/has the bug)

You need to follow step one listed on that post or the instructions outlined on my blog.

But essentially solution one there solves the problem the problem is up and too today or Sunday when live sinking of the zone was happening it would take.

You to do this over several manual sync windows meaning you would have to change it wait for a sync add to Cloudflare change the name servers again and wait for a sync.

Thank God this didn’t go the expected 2 to 4 weeks initial estimate.

Essentially this issue would normally be easy to fix and currently is quite easy to fix given live syncing of the zone is available again. But initially it was coupling too issues together with a long turnaround time to resolve.

1 Like

I’m sorry I literally have no idea what you’re trying to say.

AUDA have re-enabled their automation, synchronization is working fine. There is nothing broken on AUDA’s side.

As I said, and this is why I’ve opened a ticket with Cloudflare, there is an issue in Cloudflare’s systems holding a bad/bugged cached response, or just being totally confused about 2LD .au domains.

I’ve managed to fix a few domains by changing DNS servers and retrying, but I’ve left one deliberately broken so that Cloudflare can actually fix the ROOT CAUSE of their issues.

1 Like

what’s that domain?


dig @q.au patsouris.au NS

; <<>> DiG 9.16.15-Ubuntu <<>> @q.au patsouris.au NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10450
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags:; udp: 1232
;patsouris.au.                  IN      NS

patsouris.au.           900     IN      NS      ns3.nameserver.net.au.
patsouris.au.           900     IN      NS      ns2.nameserver.net.au.
patsouris.au.           900     IN      NS      ns1.nameserver.net.au.

;; Query time: 24 msec
;; WHEN: Mon Mar 28 21:48:54 UTC 2022
;; MSG SIZE  rcvd: 110


The nameservers there are not responding properly, that is the likely cause.


That was not the case when this issue first cropped up and it was a multistep process to fix this simple error during that manual sync of the zone period at the beginning.

It was luckily resolved as I stated officially on Monday but users have reported the things that started syncing again mid Sunday afternoon.

From searching around on here and looking at that link that you provided in your first reply to me this issue has existed for quite awhile.

And the solution like in that article you link has been pretty much what was outlined.

Following the steps resolves the issue and it’s even easier to fix now that you don’t have to wait for a sync event to happen.

The ones that I did yesterday Monday were fully fixed within about 20 minutes after changing back to the registrars name servers waiting the 20+ minutes and switching back to Cloudflare’s

Much quicker resolution now then initially if you tried to complete this task on launch day.

Given this seems to be a common issue reported on here I wish you the best of luck with that most people just wanted to get there domain names up on launch day.

That has never been a requirement. In fact, one of the great things about Cloudflare is (was?) that you could spin up your domain AFTER your existing DNS servers vanished from the internet, and rebuild your DNS from the ground up.

I even have my default DNS servers at Synergy set to owen and elsa, so I can buy a domain, and instantly set it up in Cloudflare. The first response in the support ticket said that I shouldn’t do that (even though it has worked previously).

If there’s now a REQUIREMENT for DNS records to exist, that’s a pretty massive and significant change that they haven’t told anyone about before now.

That response is absolutely correct. This conversation is going more and more off topic but you should be aware of the risks associated with changing your nameservers to Cloudflare’s before adding the site to your account. You are changing the nameservers to point to a service that you don’t yet control. Cloudflare has over 2,500 nameserver combinations but there are a lot more than 2,500 accounts. The nameserver pair you are changing to won’t be unique to you. This is why nameservers are domain specific, not account level. When you add a domain, by default you will use the same pair of nameservers as the rest of your domains, however if the domain has already been added to another accout with the same pair, you will be given different ones to point to. This ensures that the domain is always under the control of the rightful owner, but only works if you follow the correct process to add the site in your dashboard and then change the nameservers to the pair requested.

This has been the case for at least several years if not longer and isn’t a new thing.


Yep which is another known issue reported in this status update on VentraIP Service Status

If you do notice any issues with DNS resolution on your .au Direct Name, please reach out to our Technical Support team for assistance.

1 Like

The topic is ‘Cloudflare is erroneously rejecting .au 2LD registrations’. Still pretty much on topic, they are rejecting it, and they shouldn’t be. I 100% can fix it by changing the DNS servers to something random, which invalidates whatever cache is caching the failure, and Cloudflare will happily accept it.

I can even set the nameservers to hosts that don’t exist at all. Cloudflare will NOT say the domain is not registered.

They are rejecting it for the same reason they reject most of the domains with this error - the domain not resolving.

This is not the case from my previous testing. It will say the domain is not registered if it does not resolve unless in some edge case.

Yeah my early searching when this issue cropped up on launch day pretty much reflects that it’s been like that for awhile.

If that was true, it would not be possible to move a domain to Cloudflare if its DNS servers had failed. That has always worked. Anyway, I don’t really know why you’re arguing with me about this. I accept that Cloudflare don’t want me to set new domains to point to owen and elsa.

At no point have they EVER required DNS records to be present. Maybe this is a change that they haven’t told anyone about. I’m ACTUALLY more annoyed that I pay them a crapload of money for Enterprise, and my ticket has been sitting there idle for a day now.

You asked a question and I’m answering it, I have no intention of having an argument. I’m just laying out the facts I have discovered from years of people having very similar issues.

It’s a requirement for the nameservers to resolve, not for there to be DNS records there.

If you have Enterprise then there may be a solution here of account level custom nameservers to let you set a default set that doesn’t change, you could talk to your account team about this.

1 Like