Since your DNS records appear to be correct and HTTP is already returning 200 OK, this may be related to GitHub Pages' domain validation or TLS certificate provisioning rather than a basic DNS configuration issue.

A few additional checks may help:

• Verify that the apex domain and www subdomain are both configured consistently in GitHub Pages and DNS.
• Recheck the DNS status using GitHub's Pages settings after allowing time for propagation and certificate provisioning.
• If the issue persists, contact GitHub Support with the authoritative DNS results and TLS error details so they can investigate the domain validation and certificate state on their side.

The SEC_E_WRONG_PRINCIPAL error suggests that the TLS certificate presented does not match the hostname being accessed. GitHub Support may need to investigate why the expected certificate is not being served.

Hopefully, GitHub can identify the cause of the persistent InvalidDNSError status.

The SEC_E_WRONG_PRINCIPAL error indicates that GitHub's edge proxy is currently serving the fallback wildcard *.github.io TLS certificate instead of a certificate issued specifically for you-me-lab.com.

This usually happens when GitHub's ACME certificate challenge gets stuck on initial validation. A few things to check:

1. Parking / Wildcard Records: Check REG.RU's DNS panel and ensure there are no lingering default parking records or wildcard * A records competing with GitHub's four IP addresses.
2. Reset the TLS Provisioning Gate: In your repo under Settings > Pages:
   • Uncheck Enforce HTTPS (if enabled).
   • Remove you-me-lab.com from the custom domain field and click Save.
   • Wait ~10 minutes for GitHub's edge router cache to clear the stale certificate binding.
   • Re-add you-me-lab.com and click Save.

Once re-added, GitHub will re-issue the Let's Encrypt HTTP-01 challenge against your A records. After the certificate issues (usually 10–20 minutes), the InvalidDNSError badge will clear and you can check Enforce HTTPS.

Your records are fine. The failed check is a snapshot taken when they were not, and the certificate error follows from that snapshot.

What InvalidDNSError means. GitHub's checker (github/pages-health-check, domain.rb) raises it only when dns_resolves? is false. It queries A, AAAA, CNAME, MX, NS and SOA for the apex through its default resolver under a 7-second overall timeout; if the combined answer is empty, or any lookup raises (SERVFAIL, timeout), the result is nil and you get "Domain's DNS record could not be retrieved". Wrong records produce other errors (InvalidARecordError, NotServedByPagesError). So this error says GitHub's resolver got nothing for the name at check time, not that your A records are wrong, and a CAA problem would surface as caa_error, not here.

What REG.RU answers now (2026-10-22 00:28 UTC, and the same at 13:55 UTC yesterday, queried directly over UDP, TCP and with EDNS): ns1.reg.ru and ns2.reg.ru both return NOERROR with the authoritative flag for A (4 records), NS, SOA, MX, and NODATA for CNAME, AAAA and CAA, each in about 170 ms. No SERVFAIL, no REFUSED, no truncation. Google DNS agrees on every type. Nothing here fails a check run today.

Why it still showed failed. Your SOA serials are timestamps: 1792531806 means the zone was changed at 2026-10-20 21:30 UTC, nearly four hours after the repo was created (17:40 UTC), and 1792610713 means another edit at 2026-10-21 19:25 UTC (the mailru TXT). The A records carry TTL 86400 and the SOA negative-cache TTL is 10800. A resolver that looked the name up before 21:30 on 10-20 (GitHub's does when you add the domain) could keep serving that answer until 21:30 UTC on 10-21. Your remove and re-add at 08:13 UTC on 10-21 (the CNAME delete and create commits) fell inside that window, so it re-asked the same cache. That window has now closed.

What to do.

1. Remove the custom domain, wait a minute, add it once. Do not repeat it; every re-add restarts the certificate request.
2. Poll GET /repos/you-me-lab/you-me-lab.github.io/pages/health (admin token). domain.dns_resolves should turn true and domain.https_eligible true with https_error null.
3. Then GET /repos/you-me-lab/you-me-lab.github.io/pages shows https_certificate.state moving to approved, usually within the hour. Only then turn on Enforce HTTPS.

The HTTPS error. The apex still serves GitHub's CN=*.github.io certificate (visible with openssl s_client -servername you-me-lab.com). That is the fallback until a Let's Encrypt certificate exists for you-me-lab.com, and SEC_E_WRONG_PRINCIPAL is just Windows naming the hostname mismatch. It clears itself after step 3; there is nothing to change on your side for it.

The distinction between DNS resolution and certificate provisioning is important here. Since both authoritative nameservers reportedly return the expected records, I would avoid making further DNS changes until GitHub's current Pages status has been checked.

A few things worth confirming:

• Check the repository's Pages settings and confirm the custom domain is exactly you-me-lab.com.
• If you have repository administration access, inspect the GitHub Pages REST API response for the domain's DNS status, HTTPS eligibility, and certificate state.
• If DNS resolution is successful but certificate provisioning remains pending or fails, provide GitHub Support with the API response, timestamps, authoritative DNS results, and the hostname reported by the TLS certificate.
• Avoid repeatedly removing and re-adding the domain, since doing so may restart validation or certificate provisioning.

The key is to establish whether GitHub currently considers the domain DNS-valid and HTTPS-eligible before attempting another reset. That should help distinguish a stale DNS-health result from a certificate-provisioning issue.