Public mesh subdomain availability

[clehner]

The DNS page says that .mesh.nycmesh.net is a public equivalent of the .mesh internal TLD, and is supposed to be "available on the entire internet": https://github.com/nycmeshnet/docs/blob/6ed7b1cea987f333d2c919e611c4255408bac978/content/networking/dns.md#top-level-domains I see that the subdomains resolve from the mesh. However, they do not resolve from the outside Internet. The NS record for mesh.nycmesh.net is ns.mesh.nycmesh.net, which has a single A record, 10.10.10.11.

Some possible solutions to this issue:

1. Update the page to clarify that mesh.nycmesh.net subdomains only resolve from the mesh.
2. Add a public IPv4 (A) and/or IPv6 (AAAA) address for ns.mesh.nycmesh.net (in https://github.com/nycmeshnet/nycmesh-dns) a. 199.167.59.10 would seem to be a candidate for this, depending on #156.
3. Add a NS record for mesh.nycmesh.net that resolves to a public IP address.

[zgiles]

Hello there. Thanks for the report. I think either due to age of the report, or perhaps something else, this issue might not be quite accurate anymore. I'm able to resolve the domain well; In fact it is in-use by many people for their VPN access. See below for some specific examples, especially even with a private IP returned via the public resolver, and a trace..

First some good old fashioned digging:

$ dig +short l2tpvpn.sn1.mesh.nycmesh.net
199.167.59.6
$ dig +short l2tpvpn.sn3.mesh.nycmesh.net
199.170.132.6
$ dig +short mail.mesh.nycmesh.net
10.70.140.70

So that's working, but where is it coming from?

$ dig +trace mail.mesh.nycmesh.net
...
net.			172800	IN	NS	e.gtld-servers.net....
;; Received 1178 bytes from 192.58.128.30#53(j.root-servers.net) in 35 ms

nycmesh.net.		172800	IN	NS	ns1dhq.name.com.
....
mesh.nycmesh.net.	300	IN	NS	nycmesh-375p-dns1-authoritative.nycmesh.net.
;; Received 112 bytes from 2402:cf80:107::1#53(ns2fjz.name.com) in 11 ms

mail.mesh.nycmesh.net.	3600	IN	A	10.70.140.70
;; Received 66 bytes from 199.167.59.11#53(nycmesh-375p-dns1-authoritative.nycmesh.net) in 20 ms

So it's working and coming in via the 199.167.59.11 authoritative nameserver.

We can also get this data via the public resolver:

$ nslookup mail.mesh.nycmesh.net 199.167.59.10
Server:		199.167.59.10
Address:	199.167.59.10#53

Non-authoritative answer:
Name:	mail.mesh.nycmesh.net
Address: 10.70.140.70

Let me know if this doesnt work for you, or if there's something else to replicate the issue.

[clehner]

Hi Zach, thanks for the info.

I'm seeing inconsistent results depending on my network (i.e. the DNS resolver on the network).

I see now that DNS resolution succeeds from some hosts that I have access to. But it does not work from my home networks using dnsmasq.

e.g.: $ dig mail.mesh.nycmesh.net

; <<>> DiG 9.16.1-Ubuntu <<>> mail.mesh.nycmesh.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23997 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;mail.mesh.nycmesh.net. IN A

;; Query time: 11 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 13 21:54:07 EDT 2022 ;; MSG SIZE rcvd: 50

Using +trace though, I see the successful result like you quoted. So I'm trying to understand what's going on. Starting from nycmesh.net, I see the four name.com NS records.

However, for mesh.nycmesh.net, I see an inconsistency. On my network I get ns.mesh.nycmesh.net.:

$ dig mesh.nycmesh.net ns

; <<>> DiG 9.16.1-Ubuntu <<>> mesh.nycmesh.net ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42748 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;mesh.nycmesh.net. IN NS

;; ANSWER SECTION: mesh.nycmesh.net. 1566 IN NS ns.mesh.nycmesh.net.

;; Query time: 4 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 13 22:03:08 EDT 2022 ;; MSG SIZE rcvd: 62

But querying the name.com servers, I get nycmesh-375p-dns1-authoritative.nycmesh.net.:

$ dig mesh.nycmesh.net ns @ns3flt.name.com.

; <<>> DiG 9.16.1-Ubuntu <<>> mesh.nycmesh.net ns @ns3flt.name.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47276 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 ;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;mesh.nycmesh.net. IN NS

;; AUTHORITY SECTION: mesh.nycmesh.net. 300 IN NS nycmesh-375p-dns1-authoritative.nycmesh.net.

;; ADDITIONAL SECTION: nycmesh-375p-dns1-authoritative.nycmesh.net. 300 IN A 199.167.59.11

;; Query time: 36 msec ;; SERVER: 2a00:edc0:107::49#53(2a00:edc0:107::49) ;; WHEN: Thu Oct 13 22:03:42 EDT 2022 ;; MSG SIZE rcvd: 107

If I query @nycmesh-375p-dns1-authoritative.nycmesh.net., I see it points to ns.mesh.nycmesh.net.:

$ dig mesh.nycmesh.net ns @nycmesh-375p-dns1-authoritative.nycmesh.net.

; <<>> DiG 9.16.1-Ubuntu <<>> mesh.nycmesh.net ns @nycmesh-375p-dns1-authoritative.nycmesh.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11839 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mesh.nycmesh.net. IN NS

;; ANSWER SECTION: mesh.nycmesh.net. 3600 IN NS ns.mesh.nycmesh.net.

;; ADDITIONAL SECTION: ns.mesh.nycmesh.net. 3600 IN A 10.10.10.11

;; Query time: 20 msec ;; SERVER: 199.167.59.11#53(199.167.59.11) ;; WHEN: Thu Oct 13 22:07:02 EDT 2022 ;; MSG SIZE rcvd: 78

I think my resolver may be getting the NS records (and/or SOA?) for mesh.nycmesh.net from nycmesh-375p-dns1-authoritative.nycmesh.net, after getting the NS record from ns*.name.com, and the result from nycmesh-375p-dns1-authoritative.nycmesh.net is overriding the result from ns*.name.com, since nycmesh-375p-dns1-authoritative.nycmesh.net is supposed to be authoritative for the mesh.nycmesh.net domain. Whereas for some reason other resolvers do not do that (maybe they combine the results? and then ignore ns.mesh.nycmesh.net. since it's not reachable). That's my best guess/understanding.

I think the NS response from nycmesh-375p-dns1-authoritative.nycmesh.net could be made consistent with what is returned from ns*.name.com by changing the NS record accordingly in the zone file. i.e. here: https://github.com/nycmeshnet/nycmesh-dns/blob/aaf63b6c6a44ef353d3ddf16ff4a63d094f09960/mesh.zone#L4 changing "ns" to "nycmesh-375p-dns1-authoritative.nycmesh.net." Or adding a second NS record (nycmesh-375p-dns1-authoritative.nycmesh.net). I would guess that would fix the issue I'm seeing. But other solutions may be possible.

Furthermore perhaps the SOA record should also be changed to use the hostname (nycmesh-375p-dns1-authoritative.nycmesh.net.), rather than using the mesh IP address (10.10.10.11); I think the MNAME in the SOA is supposed to be a domain name and match one of the NS records (the primary nameserver): https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13 But I don't know to what extent that is needed.