nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

DNS issue with Cloudflare

ANGELO SERRA

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,

Angelo Screenshot 2022-08-16 085842.jpg

Accepted answers

Andy Heinzer

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.

All comments

Andy Heinzer

Hi,

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]"

ANGELO SERRA

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

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

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,

Angelo Screenshot 2022-08-19 102428.jpg Screenshot 2022-08-19 102506.jpg

Andy Heinzer

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

atl-rvw