"brad" == brad <bkn@ithryn.net> writes:
brad> On Nov 12, 2021, at 19:34, John Stoffel <john@stoffel.org> wrote: brad> "brad" == brad via WLUG <wlug@lists.wlug.org> writes: brad> To quickly summarize my problem/question, I’d like to host a brad> nextcloud server at my house and be able to access it with the brad> same hostname whether I’m home or away. brad> I own a domain, let’s call it example.com. Its main DNS record brad> points to a node at digital oceans. However I’d like to host a brad> sub-domain at my house, let’s call it brad> home.example.com. Currently home.example.com resolves to a brad> routable IP address at my house. brad> - When I’m on the road, I’d like to be able to connect to https://home.example.come brad> - When I’m home, I’d like to be able to connect to https://home.example.com. brad> The above works on a well-behaved desktop receiving dns servers brad> via dhcp. Specifically, I have setup local dns to resolve brad> home.example.com to 192.168.1.1. Searching this topic has taught brad> me that this method is called Split-DNS. brad> However android and iOS do not appear to honer my local dns brad> server — I’m not sure why — so they resolve the address to a brad> routable IP and connect from within the private 192.168.1.0 brad> subnet. My firewall sees this and drops it b/c it is a brad> non-routable IP address connecting to the external interface. (I brad> got this info by running tcpdump and watching traffic). brad> Are your iphone and android getting their data from the Wifi network brad> or their phone network? brad> This is a great question and led to what I believe is the solution. brad> You might need to sniff port 53 traffic on brad> your firewall and see where they're sending queries to. Then you brad> might need to block or redirect those queries to your own internal DNS brad> server. brad> I did sniff port 53 (and 853) to observe dns traffic. I also brad> sniffed port 67 and 68 to make sure that the DNS server was brad> getting sent w/ the dhcp request. All was good on the dhcp brad> front, and port 53 sniffing did display the fact that my brad> internal domain names were getting resolved to CNAMEs, but on brad> Andoird, it stopped at that step. I.e. android got a CNAME for brad> up.internal.example.com, but did not resolve the CNAME any brad> further. Interesting, I'm kinda surprised. brad> Has anyone attempted something similar? Is there something I’m brad> overlooking? (Probably) You might need/want to reboot the Android, or see if there's a way to flush it's own internal DNS cache. But I don't have any android to play with at home. brad> I've been meaning to do it myself, putting in a local internal brad> override for my dynamic DNS external name, so I can conncent from both brad> inside and outside (when I'm on the $WORK VPN mostly) without having brad> to remember things. Silly to bounce SSH across the country to get brad> downstairs... but when you sit at a $WORK laptop most days... it's brad> nice to be able to hit home stuff via SSH and screen. brad> Agreed, I recently setup wireguard to use as VPN for this brad> purpose. I just ssh home, no really need for wireguard at this time. brad> My goal is to not do special configurations on enduser devices. A laudable goal for sure! brad> What is your firewall or router at home? Depending on what you have, brad> you might be able to block outgoing port 53 traffic, or redirect it to brad> your internal DNS server so those devices get the results you want. brad> I use OpnSense at home, so if that's what you're using, we can work brad> together on this. brad> My firewall is openbsd — my preferred firewall OS as I love pf — brad> and my name server is unbound. I believe OpnSense is built on a brad> BSD, so unbound maybe an option for you. I'm already running unbound as my internal DNS server. brad> On to the solution, or at least ‘what works for me’. As far as I brad> can tell unbound is not an authoritative name server, so I had brad> to change all the CNAMEs to A records. That is a little annoying brad> when I comes to my config file, but it does work. No, unbound works just fine as an authoritative nameserver from what I know. It's dnsmasq which doesn't work as an authoritative. I think the solution of using A records is actually the right one, since you want to override the outside world's A record for your hostname, so using a CNAME inside isn't going to really help because it will lookup the name, and I *think* A records are a higher priority than CNAMEs in the response. So just doing a CNAME won't do the trick. Since it's not something that changes often, having to buidl your own A record shouldn't be that big a deal. brad> For your reference, a related bug report for opnsense is linked brad> below with subsequent links about why unbound and CNAMEs do not brad> go together. brad> https://github.com/opnsense/core/issues/1041 This is an old bug, I'm running the latest production release of OpnSense and unbound, so I think I'm ok. brad> Thanks for provoking my curiosity into the eventual solution! Excellent! John