(Sub)Domain pointing to MyFritz-Adress

Question

Following situation: I got a server at home which runs a NextCloud Docker, which is reachable through Port 8080. Since I need to make it accessable for others (without VPN) and I got a DS-Lite + IPv6 connection, I used the MyFritz-Adress and PortForwarding to access it from outside my network via

http://server.XXXXXXXX.myfritz.net:12345

where server is my device and XXXXXXXX.myfritz.net is the MyFritz-Adress. This works perfectly fine. But since this is quiet ugly, I wanted to use my domain habun.de, which I purchased from Hostinger.com, to make it prettier.

For that I made a CNAME DNS-Record

Type: CNAME
Name: pine
Priority: 0
Points to: pine.XXXXXXXX.myfritz.net
TTL: 14400 (default)

Then I added http://pine.habun.de to the DNS-Rebind-Protetion and waited around 24h (DNS Propagation?). In theory I should be able to access my Cloud now from http://pine.habun.de:8080 but I can't... FireFox says "Server not found" (Tried cleaning cache and other browser as well)

So I tried two other DNS-Records

Type: CNAME
Name: home
Priority: 0
Points to: XXXXXXXX.myfritz.net
TTL: 14400 (default)

where https://home.habun.de should lead me to my FritzBox and

Type: CNAME (ALIAS)
Name: @
Priority: 0
Points to: XXXXXXXX.myfritz.net
TTL: 14400 (default)

where https://habun.de should lead me to my FritzBox as well. Added both hostnames to `DNS-Rebind-Protection and waited 24h again, but still can't access my FritzBox... Same error as before.

Then I asked the support of Hostinger and they recommended deleting the default A Record, which I did and waited again 24h, but still the same error...

Right now I only have the 3 CNAME, a bunch of default CAA and 2 NS Records. The NameServers are the default NameServers of Hostinger.

I looked at various instructions but they all said I can just make a CNAME Record pointing to the MyFritz-adress... Did I overlook something or does anyone have an idea what could be the issue?

Edit: habun.deis the actual domain I have and the nameservers are the default nameservers of Hostinger

ns1.dns-parking.com
ns2.dns-parking.com

EDIT 2: Turned out that everything was correctly setup and the issue was with Hostinger. My domain wasn't delegated to 'de' correctly. Solved by temporarily switching NameServer and then back to Hostinger NameServes, which resynced my domain. Now everything works as it should. Solution came from @user1686 (see the discussion in the comments to his/her post).

Answer 1

Assuming habun.de is your real domain, it is currently not delegated in the de zone at all, meaning DNS resolvers don't even get to see your CNAME records.

(In other words, the pointer from de to habun.de is broken.)

The NS records at the root of your zone are mostly irrelevant – what matters is the NS records that your registrar (Hostinger) submits to the parent de registry, where the actual delegation to your nameservers is set up. Right now, however, all of the nameservers for de report that they have no NS delegation records for habun.de at all.

What the de zone (and the registry's WHOIS database) instead has is, unusually, just an A record:

habun.de. IN A 93.180.69.101

(This points to an IP address belonging to "PCextreme B.V." in the Netherlands.)

Normally this should not happen – there should only be NS (and optionally DS) records at this position. It is not unusual for A/AAAA records to be uploaded to the parent zone as "glue" records, but they must be on a subdomain (e.g. if the NS records had example.com. NS ns1.example.com., then the registry would necessarily have ns1.example.com. A as well).

You should review the "Domain nameservers" configuration at Hostinger (which is somewhere separate from the DNS records section).

---

"24 hour DNS propagation" is mostly a myth, as active propagation only happens between the authoritative nameservers where you're editing the DNS records (e.g. Hostinger's ns1/ns2/ns…) and generally takes a few minutes at most. The rest of the world queries everything "on demand" – your DNS records are either a) unknown until someone asks for them, in which case the new value will be seen immediately, or b) the old value is cached, in which case the old value will be seen for at most the "TTL" that it had before the change. (If the domain didn't exist, that fact is cached for the "minimum TTL" set in your SOA record, which is indeed often set to 24 hours.)

The actually important part of the above is the distinction between "authoritative servers" and "the rest of the world". Before waiting hours for caches to expire, you can start by directly querying the authoritative nameservers that are supposed to hold your data, and make sure they report a value that looks correct. For example, to check your CNAME entry directly at Hostinger:

C:\>  nslookup pine.habun.de ns1.dns-parking.com

$ host pine.habun.de ns1.dns-parking.com

and to check the delegation records from de to your domain:

C:\>  nslookup -q=NS habun.de a.nic.de

$ host -t NS habun.de a.nic.de

$ dnstracer -s . habun.de

It is also a good idea to temporarily reduce your record TTLs if you plan to experiment with a bunch of changes. For example, you could set a subdomain's TTL to 5 minutes (and set the SOA "minttl" to 5m as well), wait for the caches to forget the old record with its old TTL, and once that's done, you'll only need to wait at most 5 minutes to see your changes worldwide.

Answer 2

Something is not configured correctly on habun.de DNS configuration:

$ dig pine.habun.de cname

; <<>> DiG 9.18.12 <<>> pine.habun.de cname
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61266
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pine.habun.de.                 IN      CNAME

pine.habun.de does not have a CNAME record configured. The same goes for home.habun.de