[Question] Are the SOA/NS records correct?

[Cellane]

First of all, thank you so much for this project! I’ve been using (/trying to use) it to keep a single subdomain pointed to my home Internet’s public IP address so that I can VPN back to the home network from anywhere, anytime – without paying for overpriced DDNS services. Thank you for this convenient package!

I wanted to ask, however, if the SOA record that is created by default is correct. Let me describe my setup:

• docker-ddns runs on ddns.milanvit.net (update API endpoints are accessible here), and I want it to manage records in the ns.milanvit.net subdomain, for example office.ns.milanvit.net
• DNS records for milanvit.net are managed on Cloudflare, and I created the following three records:
  • Type: NS, name: ns, value: ddns.milanvit.net
  • Type: A, name: ddns, value: <ipv4-address-of-my-server>, not Cloudflare-proxied
  • Type: AAAA, name: ddns, value: <ipv6-address-of-my-server>, not Cloudflare-proxied
• I run docker-ddns in Dokku, with the following configuration:

$ dokku config ddns
=====> ddns env vars
DOKKU_APP_RESTORE:       1
DOKKU_CHECKS_DISABLED:   _all_
DOKKU_DOCKERFILE_PORTS:  53/tcp 8080/tcp
DOKKU_PROXY_PORT_MAP:    http:80:8080 https:443:8080
DOKKU_PROXY_SSL_PORT:    443
RECORD_TTL:              3600
SHARED_SECRET:           supersecret
ZONE:                    ns.milanvit.net
$ dokku storage:report ddns
=====> ddns storage information
       Storage build mounts:
       Storage deploy mounts:         -v /var/lib/dokku/data/storage/ddns:/var/cache/bind
       Storage run mounts:            -v /var/lib/dokku/data/storage/ddns:/var/cache/bind
$ dokku docker-options:report ddns
=====> ddns docker options information
       Docker options build:
       Docker options deploy:         -p 53:53 -p 53:53/udp --restart=on-failure:10 -v /var/lib/dokku/data/storage/ddns:/var/cache/bind
       Docker options run:            -v /var/lib/dokku/data/storage/ddns:/var/cache/bind
$ dokku proxy:report ddns
=====> ddns proxy information
       Proxy enabled:                 true
       Proxy port map:                http:80:8080 https:443:8080
       Proxy type:                    nginx

In other words, mount /var/cache/bind as persistent storage, make port 53 (both TCP and UDP) directly accessible, and proxy port 8080 through nginx; on top of that, manage subdomain ns.milanvit.net. I hope all of the above is correct and expected.

Now to my question, finally 😅 After setting everything up, I ran a few dig commands, with not always correct results:

$ dig @1.1.1.1 +short ns.milanvit.net NS
localhost. # incorrect
$ dig @8.8.8.8 +short ns.milanvit.net NS
localhost. # incorrect
$ dig @1.1.1.1 +short ddns.milanvit.net A
<correct IPv4 address>
$ dig @1.1.1.1 +short ddns.milanvit.net AAAA
<correct IPv6 address>
$ dig @1.1.1.1 +short <subdomain>.ns.milanvit.net
<SOMEHOW correct IPv4 address from docker-ddns>
$ dig @8.8.8.8 +short <subdomain>.ns.milanvit.net
<now that I’m writing this, it’s also correct but it definitely wasn’t 5 minutes ago>

And for example, if I run a dig on the server running docker-ddns:

$ dig @127.0.0.1 <subdomain>.ns.milanvit.net                                                  Čt 23. dubna 2020, 09:08:26 JST

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> @127.0.0.1 <subdomain>.ns.milanvit.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54383
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9589e6d074039310da7536b55ea0dc928ee6ca78a38cc782 (good)
;; QUESTION SECTION:
;<subdomain>.ns.milanvit.net.          IN      A

;; ANSWER SECTION:
<subdomain>.ns.milanvit.net.   3600    IN      A       <correct IP address>

;; AUTHORITY SECTION:
ns.milanvit.net.        86400   IN      NS      localhost. # that’s not right, right?

;; ADDITIONAL SECTION:
localhost.              604800  IN      A       127.0.0.1
localhost.              604800  IN      AAAA    ::1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 23 09:08:50 JST 2020
;; MSG SIZE  rcvd: 160

I wonder, are the NS and SOA records correct? Should they really point at localhost? Or is it something that we should manually change after the zone files are initially created? I originally thought it’s a problem with my DNS configuration, but after asking the same question at Cloudflare Community Forums, I was told it’s configuration problem…

Sorry for very lengthy explanation, but thank you for your insights!

[develroo]

From the looks of it you are trying to manage a subdomain of the nameserver (ns) That seems a little unusual to say the least. ns.domain.net should be a separate record and all the subdomains should be subdomain.domain.net.

So why do you not just have office.domain.net record ?

[Cellane]

@develroo Oh, is it an unusual scenario? I’m sorry, I thought that this was (one of) the intended usages of this project.

Just to make sure I’m explaining things right, my goal is to keep my current DNS records with my current DNS provider (Cloudflare) for various reasons (cache, stability, etc.), but delegate a single subdomain as a new DNS zone and have this zone managed dynamically by this project. That zone would contain records whose addresses change frequently (IP address to office, to home, etc.) and would be impractical to continue updating those using Cloudflare.

Of course, if I had another domain to spare, I could manage the entire domain’s records with this project, but I thought that managing only a subdomain/sub-zone with this project is something that’s supported.