mobile devices often do not use the local DNS server any more for various reasons. To my knowledge, there are no general workarounds, especially if you cannot manipulate the device itself. As a result, resolving local names sometimes works, sometimes doesn't.
Therefore, it would be useful to synchronise hostnames to a public DNS server, where it can be resolved by any DNS server the device uses, such as 8.8.8.8. The sync would include static and dynamic hostnames that dnsmasq on the router knowns of. They could be synced to a zone like local.mydomain.com using e.g. the AWS API, or a bind zone transfer/update.
Has this been done in OpenWRT? Can you think of alternative ways?
Even if you push local names to a public DNS, name resolution is going to fail for the local domain. Besides, a public DNS that issues local IP addresses is going to cause trouble.
On the other side, you can use the firewall in the router to redirect all DNS requests to the local DNS.
Are global IPv6 addresses protected against rebind attacks because they are harder to guess? Though the router address probably is easy to guess if you know the IPv6 address of a computer since they often are assigned the ::1 interface identifier.
Rebinding attacks against global (public) IPv6 would be harder to detect because the IP's scope isn't implied, as opposed to an IP that falls within one of the ranges reserved for private use (e.g. fc00::/7 and 192.168.0.0/16). Keep in mind rebinding attacks not only target internal resources on private networks, but target internet-facing services as well, so guessing wouldn't be required for those.
For attacks against internal resources, it's easier to detect because it's a bit suspicious if some random organization's forward zone has a record pointing to an address in my network, regardless of whether the internal addresses on my network are private or global in scope.
If I were implementing rebinding detection, I'd trigger on any external DNS response pointing to an IP that is on a prefix on the local network. Of course wouldn't help if the attack is against a 3rd party internet service.
@irxy Sorry to go off on a tangent. I'd use the built-in functionally in most DHCP servers to do dynamic updates against your forward zone. Most likely you would only get caught up in rebinding detection if you are creating records for private addresses. But I think it's highly unlikely mobile devices actively detect this as this isn't (to my knowledge) a defined standard, but that could change in the future.
Keep in mind PTR records are probably not going to be feasible because, most likely, you don't control the reverse zone for your globally scoped addresses, unless you're lucky enough to have a provider who is willing to delegate. Even then PTR RRs for private IPs would be useless because your mobile devices, in this scenario, would ignore your internal DNS server. At best you'd have PTR records for IPv6, but not for IPv4.
Public DNS zones MUST NOT contain [RFC 1918] addresses, or any other addresses designated by IANA as private, in any resource records. The situation with public network addresses is more complicated because the Internet cannot in general be cleanly divided into "public" and "private" parts in this case. https://tools.ietf.org/id/draft-ietf-dnsop-dontpublish-unreachable-01.txt
You'll probably have a difficult time getting a free-standing public DNS service to accept Private IP ranges.
One thing you might consider for your mobile applications would be a VPN which would force the device to recognize the internal local DNS for use when outside the network, or maybe use the .lan zone built in when inside (ex: openwrt.lan opens the luCi interface)
yes, but at that point, if you're running a local DNS zone that is only connected from inside private zone, then rolling the local CA as well shouldn't be that much of a stretch. Whether you're doing it from inside OpenWrt or via other infrastructure on the network.
Public DNS is going to require a public IP - Just to test this, I attempted to add a 10.x.x.x address to my Google DNS record and it didn't even try.. just error'ed and said "nope".
This would mean installing the Cert on client machines, but you would be doing that anyway in some form or another for TLS-decryption of the traffic (which would also solve the DoH side-stepping issue if everything is shoved through a proxy).
Don't get me wrong, I'm also looking for an viable non-PITA way to maintain a local vs public DNS, but the only way I've found is to split the zone between Intranet vs Internet. The subdom is probably the way to go and stub off the local zone (local.mydomain.com is handled by the local DNS, so server1.local.mydomain.com would only appear inside the network, but the anything else is handled externally).
Going back to the original question: since local IP addresses can be static, and you seem to have your own domain, perhaps you could try to give a static IP address to the main devices in your network, the configure those addresses on the DNS that serves your domain.
Your issue would be differentiation of the machines once you get past the edge device - All the internal DNS would still have to be done on that device to some extent
You could port-forward, but then you're having to manually update the port-map on the router and hope they don't overlap (or force them not to by using a non-standard port). You could do this approach with a static or DDNS and not need to hold more than the CNAME publicly. But this isn't really DNS anymore than using a hosts file would be, so I don't know if it would satisfy what @irxy was wanting to accomplish.
The only real way I could see doing something like this would be to run dnsmasq or some other DNS server locally and make it the authoritative zone publicly (pointing the domain DNS records back to your publicly available local DNS service). This would assume that port 53 inbound isn't blocked by the ISP. If you're running the DNS for the zone, you can do what you want, but you assume all responsibility for it (and redundancy). This is similar to what you were suggesting @eduperez with the DNS redirection to local at the firewall, but global scope.
## DNS forwarder
The DNS forwarder (dnsmasq) uses the option –stop-dns-rebind by default, which rejects and logs addresses from upstream nameservers which are in the private IP ranges. In the most common usage, this is filtering DNS responses received from the Internet to prevent DNS rebinding attacks. Internet DNS responses should never come back with a private IP, hence it’s safest to block this.
There are some cases when public DNS servers have private IP address replies by default, though it is not recommended. In those cases, DNS rebinding can be disabled or an override may be placed in the DNS Forwarder Advanced Settings box as follows:
rebind-domain-ok=/mydomain.com/
Note this is automatically overridden for domains in the DNS forwarder’s domain override list, as the most common usage of that functionality is to resolve internal DNS hostnames.
