.AU Domain adding to Cloudflare

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?

patsouris.au

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;patsouris.au.                  IN      NS

;; AUTHORITY SECTION:
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
;; SERVER: 65.22.196.1#53(65.22.196.1)
;; WHEN: Mon Mar 28 21:48:54 UTC 2022
;; MSG SIZE  rcvd: 110

image

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

https://dnsviz.net/d/patsouris.au/dnssec/

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.

2 Likes

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

I also assumed that you could do that and the same CF name servers would be tied to your CF account. But I did once do bulk CF API account domain setups and scripted it to assume the same CF name servers would be assigned to all domains bulk added to my CF account. But turns out one of the domains got a different assigned CF nameserver from the rest!! So I had to rewrite my CF API bulk domain adding scripts to actually grab the CF nameservers assigned on CF API JSON output instead as it looks like you don’t always get the same CF nameservers.

1 Like
[email protected]:~/fax# 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: 1026
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;patsouris.au.                  IN      NS

;; AUTHORITY SECTION:
patsouris.au.           900     IN      NS      ns1.nameserver.net.au.
patsouris.au.           900     IN      NS      ns3.nameserver.net.au.
patsouris.au.           900     IN      NS      ns2.nameserver.net.au.

;; Query time: 28 msec
;; SERVER: 65.22.196.1#53(65.22.196.1)
;; WHEN: Mon Mar 28 22:13:49 UTC 2022
;; MSG SIZE  rcvd: 110

[email protected]:~/fax# host ns1.nameserver.net.au.
ns1.nameserver.net.au has address 112.140.176.177
ns1.nameserver.net.au has IPv6 address 2400:b800:0:1::11
[email protected]:~/fax#

Is that not the nameservers resolving?

Yeah, I’ve noticed that - I’ve only had a handful of domains need different nameservers previously, and it’s not like I register a million a day, so I’ve just handled the edge cases manually. And look, if Cloudflare want to tell me to stop doing that, I’ll stop doing that. It was just super convenient.

Not consistently:
patsouris.au | DNSViz

DNS Checker - DNS Check Propagation Tool

1 Like

I don’t know why you keep pointing at Ventra, they’re not AUDA, and they’re not Synergy.

Nope, they do not resolve themselves. You setting the domain to them is not enough.

Try querying them for the NS of your domain.

% dig patsouris.au @ns1.nameserver.net.au ns

; <<>> DiG 9.10.6 <<>> patsouris.au @ns1.nameserver.net.au ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55284
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;patsouris.au.			IN	NS

;; Query time: 283 msec
;; SERVER: 2400:b800:0:1::11#53(2400:b800:0:1::11)
;; WHEN: Tue Mar 29 00:18:31 CEST 2022
;; MSG SIZE  rcvd: 30

They should reply like this.

% dig cloudflare.com @ns4.cloudflare.com ns

; <<>> DiG 9.10.6 <<>> cloudflare.com @ns4.cloudflare.com ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41807
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 21
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare.com.			IN	NS

;; ANSWER SECTION:
cloudflare.com.		86400	IN	NS	ns3.cloudflare.com.
cloudflare.com.		86400	IN	NS	ns4.cloudflare.com.
cloudflare.com.		86400	IN	NS	ns5.cloudflare.com.
cloudflare.com.		86400	IN	NS	ns6.cloudflare.com.
cloudflare.com.		86400	IN	NS	ns7.cloudflare.com.

;; ADDITIONAL SECTION:
ns3.cloudflare.com.	900	IN	A	162.159.0.33
ns3.cloudflare.com.	900	IN	A	162.159.7.226
ns3.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:21
ns3.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:7e2
ns4.cloudflare.com.	900	IN	A	162.159.1.33
ns4.cloudflare.com.	900	IN	A	162.159.8.55
ns4.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:121
ns4.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:837
ns5.cloudflare.com.	900	IN	A	162.159.2.9
ns5.cloudflare.com.	900	IN	A	162.159.9.55
ns5.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:209
ns5.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:937
ns6.cloudflare.com.	900	IN	A	162.159.3.11
ns6.cloudflare.com.	900	IN	A	162.159.5.6
ns6.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:30b
ns6.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:506
ns7.cloudflare.com.	900	IN	A	162.159.4.8
ns7.cloudflare.com.	900	IN	A	162.159.6.6
ns7.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:408
ns7.cloudflare.com.	900	IN	AAAA	2400:cb00:2049:1::a29f:606

;; Query time: 50 msec
;; SERVER: 2400:cb00:2049:1::a29f:121#53(2400:cb00:2049:1::a29f:121)
;; WHEN: Tue Mar 29 00:19:40 CEST 2022
;; MSG SIZE  rcvd: 573
3 Likes
  1. auDA Are not communicating these issues directly to consumers it goes via the registrars. That status page is for the registry level issue related to zone syncing.

  2. VentraIP in Synergy Are the same organisation they’re owned and operated by the same people one is their retail division one is wholesale.

Those name servers that you had set belong to Synergy Wholesale and VentraIP’s customers run on top of Synergy Wholesale.

And this is a known issue that their advisory says you can contact them so contact synergy support. It’s somewhat related to the switch from manual zone syncing to automated again.

1 Like