GitLab Pages DNS TXT propagation

I changed the TXT record of my domain well over 24 hours ago and I am getting the correct domain and registrar in the output but for some reason it doesn’t show the correct value, and instead the “IN SOA” with the nameserver is shown. I guess this is why the verification doesn’t work either. Do I maybe have to adjust the nameservers to the GitLab pages server as well?

dig TXT

; <<>> DiG 9.10.6 <<>> TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14418
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096

;; AUTHORITY SECTION:		3600	IN	SOA 2019112602 86400 10800 3600000 86400

;; Query time: 59 msec
;; WHEN: Wed Nov 27 11:46:45 CET 2019
;; MSG SIZE  rcvd: 137

The solution here didn’t work for me.


the AUTHORITY section is always added in case of errors. opcode: QUERY, status: NXDOMAIN is important, NXDOMAIN says that the requested record does not exist.

Neither does it return anything else with any instead of TXT.

Reading the docs entry it would be interesting to know whether your subdomain is using an A or CNAME record. Can you share these details? A screenshot of your current provider settings web interface also is sufficient.

Also, the zone has a TTL of 86400 (1d). This could be lowered to e.g. 3600 for changes like this to allow resolvers to update this more frequently.


Hi! :slight_smile:

I did set up an A record AND a CNAME at the same time before. I tried out different things and removed the A, or the CNAME. But could well be that I didn’t wait long enough for the changes to take effect.

Right now it’s like this:


if I understand the docs correctly you’d

  • either have an A record and put the TXT record right into the same zone, no sub entry.
  • or you’ll create a CNAME pointing to a subdomain, and then use the _gitlab-pages-verification-code sub entry.

Is the primary FQDN where you’d want to access GitLab pages from? If so, try adding a TXT entry in the main @ area.

@  IN TXT "gitlab-pages-verification=...."


1 Like

Wow. Thanks. That actually was the cause.

I’ve been reading different docs though. Apparently there’s some discrepancy between the two.

That’s the link provided on the domain edit page of gitlab pages, where it says “Learn more about adding certificates to your project by following the documentation on GitLab Pages.

1 Like

Oh. Yeah, I’ve noticed that with the CI help as well. I’ll open an issue to help align them.

Funny thing is, that I have never used GitLab pages til now. I just have a strong DNS background from my former employer :slight_smile: Glad this worked out so well for your :heart:


Just chiming in here: I’ve just found this epic where should exist as single source of truth.

So we can work with always up-to-date docs :slight_smile:


Hi all,

I struggle with the same problem and are not sure if I understand the solution(s)

Does this mean (opposed to the documentation) I have to add:  A
@              TXT	"gitlab-pages-verification=...."

(can I use an @ instead of

!!! It works :-)!!!

The documented way doesn’t work at all?

DNS CNAME TXT gitlab-pages-verification-code=xxxx

Or do I have to create the _gitlab-pages-verification-code subdomain (weren’t _ illegal in DNS records???) and add a TXT record for this. And this only works if you don’t have an MX record?
(funny enough I get an Längenüberlauffehler (Input length overflow error) when trying this in the DNS Admin UI)



the TXT record is used by the pages setup to verify that you are the domain owner, basically a trusted key. You probably know that from setting up Google analytics where you put a specially crafted HTML file into your web root, that’s basically the same mechanism but with DNS TXT records.

The documentation shows two different paths:

  • as root domain, setting the A record.
  • as sub domain, using a CNAME record

Root Domain

For the root domain parts, you’ll need to set the A record and TXT record into the main root zone directly.

Note that @ is a placeholder in a zone file for the current domain, e.g.

Below is a raw Bind zones conf entry, the IN may be hidden in your config forms.

@ IN A

@ IN TXT "gitlab-pages-verification=...."


For the subdomain method, this needs to be a CNAME pointing to using this sub domain entry my-pages, and later the Let’s Encrypt certificates.

my-pages IN CNAME

_gitlab-pages-verification-code IN TXT "gitlab-pages-verification=...."


In your example, you need to go the first path with the Root domain.

An MX record is a different entry in your DNS zone, that is required for mail server responsibility for a zone. Whenever you send an email to a specific domain, their MX record qualifies the receiving mail server. That is mentioned in the banner where it advises against something, I see how this is complicated.

Imho the CNAME would collide with the MX record for the zone. When you run a mailserver for the zone, you should avoid CNAME records and only use A records for the root domain.

The apex of a zone needs explanations, like this entry: or

The following might not work within mail server communication, not fully resolving the CNAME.

If being the root of the zone now (think of the @ placeholder above), the CNAME hurts all other records like MX on the same level.


mail IN A <actual mail server IP>

@  IN MX 10 mail

I can only advise against the above, and instead use A records.

@ IN A

mail IN A <actual mail server IP>

@ IN MX 10 mail

That being said, you need to use the GitLab’s pages IP address for setting up the entry. If that gets renumbered at some point, you need to update your DNS zone. These renumberings are done with care affecting lots of services, so you should find a pre announcement on the blog for sure.

No, they are allowed. You may have seen them specifically with SRV records, that’s something used within Microsoft AD server setups. Typically an underscore prefix means that this is something “internal”, or “for configuration only”. Nothing which should be treated as domain entry you type into your browser.

Can you share a screenshot, or which provider you’re using?

Agreed, the docs would need more howto-alike-instructions. We are tracking this in this ussue:


1 Like

Thanks for your detailed explanation. It makes it much clearer.
My DNS experience is a bit ancient :slight_smile:

The first path worked and my Gitlab-pages are now reachable through HTTP under my domain
(I’m still waiting for the letzs encrypt certificate to start working, but that is not DNS related :wink: )

My domain registrar is GoDady
(btw, how did you get the fantastic quoting?)

If I try to generate the _gitlab-pages-verification-codesubdomain I get the said error (using www works). "Which roughly translates to [Input] Length Overflow.


I used to work at the University of Vienna in the Domain Administration team, which also has a cooperation with, hence my nickname :wink: 7 years ago, I moved to Nuremberg following my open source adventure with Icinga, a monitoring solution.

I think there are some problems with Let’s Encrypt rate limiting via these days. There is a topic and tracking ticket here: GitLab Pages custom domain Let's Encrypt SSL certificate not completing

When ever you mark a text block in Discourse, there is a popup saying "Quote, klicking that inserts that into the current cursor scope. I use that a lot with making context more readable, also in other communities like Icinga.

When you registered here, you should have gotten a message from @discobot - this is an interactive tutorial which teaches you how to quote, like, format, etc. You can even get a badge when completing the basic and advanced tutorials. I’ve added some insights here: Community first steps: Explore Discourse with discobot

Sounds like GoDaddy has a length limit for subdomain entries. Best would be to report that error via their support form.

Maybe there is a possibility to edit the “raw” DNS zone, e.g. Hetzner allows for that.


1 Like

Hi! To find out what I can do, say @discobot display help.