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?
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.
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.
DNS my-domain.com CNAME my-project.gitlab.io.
_gitlab-pages-verification-code.my-domain.com 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.
For the subdomain method, this needs to be a CNAME pointing to my-project.gitlab.io using this sub domain entry my-pages, and later the Let’s Encrypt certificates.
my-pages IN CNAME my-project.gitlab.io
_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 following might not work within mail server communication, not fully resolving the CNAME.
If my-project.com being the root of the zone now (think of the @ placeholder above), the CNAME hurts all other records like MX on the same level.
@ IN CNAME my-project.gitlab.io
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 126.96.36.199
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:
I used to work at the University of Vienna in the Domain Administration team, which also has a cooperation with nic.at, hence my nickname 7 years ago, I moved to Nuremberg following my open source adventure with Icinga, a monitoring solution.
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.