DNS issue with Cloudflare

ANGELO SERRA August 16, 2022

hi everyone, I am currently testing the free version of Jira Software and it seems very good!

I am thinking to upgrade to the pro version, but I am a bit confused about what is happening with DNS verication.  I have added (as suggested) all the values on my Cloudflare, but only one has been validated. I tried to take a look at the community but I haven't found anything helpful. Is there someone else who faced and solved it?

Any help would be much appreciated!

Thank you in advance,

AngeloScreenshot 2022-08-16 085842.jpg

 

2 answers

1 accepted

1 vote
Answer accepted
Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 17, 2022

Hi,

The free vs paid site won't make a difference here.  It looks like you are trying to follow the steps in https://support.atlassian.com/user-management/docs/verify-a-domain-to-manage-accounts/#Verify-over-DNS

But I can see that you are missing several expected DNS records here.  For example, when I ran a terminal command to lookup the DNS txt and cname records of your domain, such as

% dig curzon.com CNAME

; <<>> DiG 9.10.6 <<>> curzon.com CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2836
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;curzon.com. IN CNAME

;; AUTHORITY SECTION:
curzon.com. 2818 IN SOA denver.ns.cloudflare.com. dns.cloudflare.com. 2286121512 10000 2400 604800 3600

^ there are no entries in the ANSWER section which would seem to indicate you don't have the 3 CNAME records we expect to see on your domain.

 

And for

dig curzon.com txt


; <<>> DiG 9.10.6 <<>> curzon.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64661
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has 60 extra bytes at end

;; QUESTION SECTION:
;curzon.com. IN TXT

;; ANSWER SECTION:
curzon.com. 300 IN TXT "MS=[redacted]"
curzon.com. 300 IN TXT "atlassian-domain-verification=[redacted]"
curzon.com. 300 IN TXT "MS=[redacted]"
curzon.com. 300 IN TXT "google-site-verification=[redacted]"
curzon.com. 300 IN TXT "apple-domain-verification=[redacted]"
curzon.com. 300 IN TXT "atlassian-sending-domain-verification=[redacted]"

The last record is correct, and verifies according to your screenshot, but the TTL (time to live) values are extremely low (300).  Our documentation indicates we expect a value of 86400 instead.  The problem can be with low TTL here is that our services would have to invalidate the cache of DNS records within 5 minutes, requiring a new lookup to your DNS server each time.  If that fails for any reason, it can also cause the check to fail.

So to fix this, you will need to copy the values on your screenshot and create the appropriate DNS records on your domain.  Once that is done, it could take a few hours for our services to automatically attempt to check this and verify again.

0 votes
ANGELO SERRA August 17, 2022

Hi Andy,

thanks for your reply, I really appreciate it.

I've just noticed the SPF record took a while for validation, and now is fine. CNAMEs are still showing an error, even though I have added them on Cloudflare, am I missing something?

 

Screenshot 2022-08-17 224930.jpg

 

Screenshot 2022-08-17 225310.jpg 

Thank you in advance for your precious help,

Angelo

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 18, 2022

Thanks for the screenshot.  It looks like the CNAME records are being proxied.  This would explain why they are not being propagated to other DNS servers yet.  I found another guide some users made over in https://easydmarc.com/blog/atlassian-spf-and-dkim-setup-step-by-step/ which indicates you need to

Note: For CNAME Records, turn off the proxy status if you’re using Cloudflare.

I suspect you will need to make that change to get this to work.  Right now it looks like the value is 'proxied' but instead should be 'DNS only'.

Try that.

ANGELO SERRA August 19, 2022

Hi Andy,

I have turned off proxy for CNAMEs , but weirdly after 24 hours nothing is working, even TXTs which were working previously.

Please note I haven't changed TXT as they were working before CNAME change.

 

Thanks again for your help,

AngeloScreenshot 2022-08-19 102428.jpgScreenshot 2022-08-19 102506.jpg

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 19, 2022

Please review https://support.atlassian.com/user-management/docs/verify-a-domain-to-manage-accounts/#Verify-over-DNS

It can take up to 72 hours for your domain to verify after the DNS changes take effect.

 

But again, you need to increase the TTL (Time to live) values of these TXT records.  According to my DNS server, your value is still 500.  But our documented guide states this value should be 86400.  Having such a low value will cause your records to time out prematurely.  Also our system is limited in regards to how often our system will check for new records.  With a very low value like yours, the record has expired before we will look it up again.  That is why the TXT records were working before but stopped now. 

ANGELO SERRA August 20, 2022

Thanks a lot for your help Andy!!!

it worked!!!!

Angelo SerraScreenshot 2022-08-20 160934.jpg

Like Andy Heinzer likes this
Chris Brock April 25, 2023

I just wanted to echo Andy's comments about TTL and Proxying related specifically to Cloudflare. Leaving the TTL set to "Auto" is not sufficient and you must increase the TTL.

Andy's comments were very helpful in troubleshooting issues we had with domain verification. After making the changes below, our domain was verified within 5 minutes.

  • Set TTL to "1 day" for all records
  • Disable Proxy and set to "DNS only" for all records
  • Optional: Add a tag to each DNS entry for easier reference in the future

 

2023-04-25_12-51-42.png

Like Doug Johnston likes this
Doug Johnston August 21, 2023

We're still seeing issues with this same error, even after setting the TTL in Cloudfront to '1 Day' several days ago. Has anyone been able to find any other solutions to this?

Screen Shot 2023-08-21 at 9.43.10 AM.png

The TXT record shows as verified in Atlassian, so I know at least something is working correctly. However, none of the CNAME records will verify in Atlassian.

Andy Heinzer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 22, 2023

@Doug Johnston When I run a terminal command of

dig example.com TXT

(where example.com is your domain), I am still seeing TTL values of 300 for all TXT records. 

Your screenshot appears to be correct as far as I can tell.  It might help to reach out to your DNS provider's support for additional help here.  If you're using Cloudflare then I found their support portal over in https://dash.cloudflare.com/?to=/:account/support

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Site Admin
TAGS
AUG Leaders

Atlassian Community Events