On Tue, 29 Sep 2020 at 17:39, mick <mbm@rlogin.net> wrote:

Try adding your local addresses to the static hosts file on the router and make sure that your resolv.conf (or whatever resolver routines you use) point to the openwrt router and that router can correctly resolve local addresses.

I'm reluctant to add the addresses elsewhere (it defeats the point of having DNS, I might as well add them to hosts on my laptop!), but I might be left with no choice. But if so I'd like to understand why. I know the authoratative DNS is set up correctly as I can resolve the hosts using dig/nslookup from my laptop (Win10, using nslookup under Windows and dig under WSL, although I now find that nslookup under WSl fails). If I try the same from the router, it queries 127.0.0.1 (dnsmasq) and gets no response. If I tell it to use Google's DNS at 8.8.8.8 it works, though, so it definitely seems to be a configuration issue within dnsmasq. (And it can resolve other hosts on the same domain that aren't 192.168.x.x addresses.) I just tried using dig from my Ubuntu desktop (behind same router) where both nslookup and dig fail. The Ubuntu box is itself, of-course, using dnsmasq. Part of my problem is finding a way to describe what is happening to ask Google and get a meaningful answer. It seems that dnsmasq is blocking local IP responses from non-local DNS servers (maybe there's a securty reason to do so but if so surely there's a way to turn that off if such responses are valid?)

I have a siilar setup, but I have two separate internal networks, each with their own DNS server running DNSmasq (and stubby for DNS encryption) I have no trouble resolving internal addresses.

Is dnsmasq ever resolving a local IP from a non-local DNS server in your configuration? (I think that's the key here.) Obviously all my comments regarding example.com are to avoid referencing the real hosts but I think maybe a real example might help, so I have just set up: alugtest.msl-office.co.uk => 192.168.0.100 Its authoritative DNS is ns.123-reg.co.uk and I just verified that it is live there now but it may take a little while to propagate beyond that. I'd be interested to know who can/can't resolve it. (Google's DNS also resolve it correctly as I write this.) -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

On Wed, 30 Sep 2020 08:49:11 +0100 Mark Rogers <mark@more-solutions.co.uk> allegedly wrote:

Re-reading the dnsmasq docs, I think this is the key:

--stop-dns-rebind Reject (and log) addresses from upstream nameservers which are in the private ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network. For IPv6, the private range covers the IPv4-mapped addresses in private space plus all link-local (LL) and site-local (ULA) addresses.

Turning off rebind protection within OpenWRT seems to have fixed my issue.

I don't think turning off dns-rebind is a good idea. It leaves you open to same origin attacks from hostile websites. (See https://en.wikipedia.org/wiki/DNS_rebinding ). Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------

On Wed, 30 Sep 2020 at 16:20, mick <mbm@rlogin.net> wrote:

Actually no, it doesn't. You are using dnsmasq to resolve your addresses so it makes perfect sense to use a local hosts file to list all your RFC1918 local addresses. Those addresses are not routeable over the wider internet so it makes no sense to query an external DNS server for such an address.

The use case is that inside my office they resolve via local DNS, but outside the office I may connect to them via VPN. Since I don't want to redirect all my DNS queries across the VPN, the external DNS solves this problem. If there's a better solution I'm interested.

It is also very confusing for anyone /outside/ your network querying your DNS and getting an address they cannot reach.

They're not intended for external use so this shouldn't apply.

However, if you do as I do, and I suggested, and use your local dnsmasq on the router to query a local hosts file for /internal/ addresses you can sucessfully get both forward and reverse answers. Any non local DNS quesries will simply be passed to the external DNS servers you use - and they /should/ have correct in-addr.arpa zone files mapping the reverse addresses.

And my colleagues will have to add them to their router DNS too, and if I want to use my laptop from a hotel they'll need to be in the laptop hosts anyway (and I have several laptops). And I have no idea how to add them to the hosts file on my phone (although I'm sure that is possible.) A single external DNS solves all that.

I don't think turning off dns-rebind is a good idea. It leaves you open to same origin attacks from hostile websites. (See https://en.wikipedia.org/wiki/DNS_rebinding ).

Indeed, and I'd like a better solution. (I only need it for a single domain but I can't see a way to limit it that way.) It worked fine before I installed OpenWRT so whilst OpenWRT's default is better than my old router's, having this open isn't unusual it seems. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

On Wed, 30 Sep 2020 at 18:16, Adam Bower <adam@thebowery.co.uk> wrote:

There's a whitelist option for domains where you want RFC1918 responses, it's in the gui on my openwrt but if you can't find it then look at:

https://openwrt.org/docs/guide-user/base-system/dhcp

and search for rebind_domains

Thanks, I'll take a look. It isn't being exposed by my openwrt gui as far as I can see but I'll see if I can find or add it. -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

On Wed, 30 Sep 2020 16:32:41 +0100 Mark Rogers <mark@more-solutions.co.uk> allegedly wrote:

The use case is that inside my office they resolve via local DNS, but outside the office I may connect to them via VPN. Since I don't want to redirect all my DNS queries across the VPN, the external DNS solves this problem.

If there's a better solution I'm interested.

Why do you not want your DNS queries to go over the VPN? Surely that is /exactly/ what you /should/ want? Certainly I always do. Anything else is a leak and a potential privacy nightmare. If you are inside your network, then the internal DNS will correctly resolve the addreses and you can reach the servers. If you are /outside/ the network, then by definition you cannot reach the internal servers unless you use the VPN, and if you are using the VPN, what is the problem with using the internal DNS?

And my colleagues will have to add them to their router DNS too, and if I want to use my laptop from a hotel they'll need to be in the laptop hosts anyway (and I have several laptops). And I have no idea how to add them to the hosts file on my phone (although I'm sure that is possible.) A single external DNS solves all that.

I'm sorry, perhaps I'm not understanding something here, but I really don't get this at all. If your colleagues are inside the office, then they use the same DNS you do, if they are outside, then they could not possibly reach the internal servers anyway (unless they too use a VPN) so what is the point of them having DNS entries on their routers (or entries on the external DNS server) pointing to the internal servers? And if they /do/ use VPNs. then again the internal DNS would resolve things correctly for them. Furthermore, if you are in a hotel (and thus outside) again you cannot reach the internal office server unless you use a VPN, and as I have said, if you use a VPN, it should resolve addresses internally so your DNS queries /need/ to go over the VPN. Same applies tp your phone. You don't need to add a hosts file to your phone, so long as it connects over a VPN and uses the internal DNS. And if it doesn't connect over a VPN, it cannot reach the servers anyway. I /really/ don't understand why you should think you need to have internal unrouteable addresses in an external DNS server.

...

I don't think turning off dns-rebind is a good idea. It leaves you open to same origin attacks from hostile websites. (See https://en.wikipedia.org/wiki/DNS_rebinding ).

Indeed, and I'd like a better solution. (I only need it for a single domain but I can't see a way to limit it that way.)

It worked fine before I installed OpenWRT so whilst OpenWRT's default is better than my old router's, having this open isn't unusual it seems.

I think Adam has answered this. Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------

On Thu, 1 Oct 2020 07:37:11 +0100 Mark Rogers <mark@more-solutions.co.uk> allegedly wrote:

On Wed, 30 Sep 2020 at 19:33, mick <mbm@rlogin.net> wrote:

...

Why do you not want your DNS queries to go over the VPN? Surely that is /exactly/ what you /should/ want? Certainly I always do. Anything else is a leak and a potential privacy nightmare.

Why would I not want all of the DNS queries which have nothing to do with my office network to go via the VPN for the sake of one or maybe two that need to go that way?

Latency. And, frankly, privacy.

The VPN is over a relatively slow ADSL link. If I had reason to want to keep my DNS queries private then there are far better options (including use of a VPN service that doesn't operate over a slow link to my office). There are lots of uses for a VPN, and one of them is to keep your network activities private but another largely independent one is gaining secure access to another network, and it's the latter usage I'm employing here.

But the idea that I should necessarily trust the VPN provider with my privacy is flawed anyway: if I'm accessing a customer's VPN then sending all my DNS requests via their DNS potentially exposes a lot of commercially sensitive information, for example you could probably glean quite a lot about who my other clients are by looking at the sites I access; as far as I am concerned *nothing* unrelated to that customer should cross the VPN to their network, quite apart from performance issues that result from it. If you consider that DNS content has any privacy implications then you surely cannot also say consider that this content should be made to any and all VPN provider you may have reason to access. (A few customers have VPNs configured such that all network traffic *must* go through the VPN once established; for those we inevitably set up a virtual machine to protect our own security and that of our other clients.)

And a third issue: how does your solution work if I have reason to access two VPNs simultaneously? (Something I do quite often: accessing a customer VPN to support their systems whilst accessing my office VPN for the resources to do so, although to date I have not needed to access resources on the customer VPN by hostname so DNS hasn't been an issue.)

...

If you are inside your network, then the internal DNS will correctly resolve the addreses and you can reach the servers. If you are /outside/ the network, then by definition you cannot reach the internal servers unless you use the VPN, and if you are using the VPN, what is the problem with using the internal DNS?

Happy to use the internal DNS, via the VPN, for queries relating *only* to domains hosted there. Is that possible with DNS? In this case I'd even accept deferring any unresolved queries to the VPN's DNS, although I'd be reluctant to do so on a general basis and again I'm not aware of this being possible.

...

I'm sorry, perhaps I'm not understanding something here, but I really don't get this at all. If your colleagues are inside the office, then they use the same DNS you do, if they are outside, then they could not possibly reach the internal servers anyway (unless they too use a VPN) so what is the point of them having DNS entries on their routers (or entries on the external DNS server) pointing to the internal servers? And if they /do/ use VPNs. then again the internal DNS would resolve things correctly for them.

They could be inside or outside the office, but when outside yes via VPN. And I have no reason to require all my colleagues DNS queries going via the office DNS - if they want to visit bigandbusty-dot-com from their home computer while connected to the office VPN is it really any of my employer's business?

The *only* traffic that should be traversing this VPN is traffic that *needs* to traverse this VPN. That might not be the case with every VPN - plenty of VPNs exist precisely so that all traffic should go through them - but that isn't the only scenario in which VPNs are used (and it's not the scenario in which I am using one here).

I have deliberately left the entire earlier discussion above so that later readers can follow it. As I said, "I'm sorry, perhaps I'm not understanding something here, but I really don't get this at all." Clearly I was missing something or misunderstanding your case. It appears that I was wrong to assume that your use case as stated: "The use case is that inside my office they resolve via local DNS, but outside the office I may connect to them via VPN. Since I don't want to redirect all my DNS queries across the VPN, the external DNS solves this problem." was the /only/ use case. You now say that both you, and colleagues use VPNs to connect not only to the office network (which presumably you control, or otherwise trust) but customer premises, sometimes at the same time. I had also assumed that you would be using /your own/ VPN and not one provided by a third party (or worse, the customer). Again that appears not to be the case because you don't trust the VPN. That muddies things. Worse it can muddy routing if your customer happens to use the same internal RFC1918 addresses as do you in your office. Sure, you should not trust a third party not to snoop your DNS queries (I care so much about that that I now actually encrypt all my DNS queries using DNS over TLS) but my assumption (given your stated use case) was that all your DNS queries could happily go over your office VPN. Not so it seems. And whilst it is your choice I admit, personally I would be /very/ bothered if anyone connecting to my protected network were using a desktop which was also used to browse "bigandbusty-dot-com" (or any other such sites). The potential for them to be malware ridden is obvious. Don't your customers care? Whatever, you seem to have solved your original problem with openwrt, so the discussion is now somewhat moot. Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------

Whilst I see what you're doing, and indeed I do similar things, you're trying to route RFC1918 addresses, so it's not hugely surprising odd things happen. On 01/10/2020 14:56, Mark Rogers wrote:

On Thu, 1 Oct 2020 at 13:05, mick <mbm@rlogin.net> wrote:

...

That muddies things. Worse it can muddy routing if your customer happens to use the same internal RFC1918 addresses as do you in your office. True, although whilst my example used 192.168.0.100 we don't actually use such a common subnet and the issue of collision has yet to occur. It would be far more likely to occur if I had reason to connect to two different customers at the same time, but that isn't something I have needed to do nor can I see it happening.

(To some degree this is all because of COVID: Sitting in the office with a connection to a customer VPN is perfectly normal, but if I am having to work from home to carry out my normal work then connecting to two VPNs becomes an issue. But if I were in the office and connected to my customer VPN, I wouldn't want to lose access to resources in the office, which would happen if my DNS queries stopped using my office DNS and instead used the VPN DNS. There are plenty of good reasons to send DNS queries over a VPN, as there is for all sorts of Internet traffic, but I personally far more frequently have a reason not to.)

...

Sure, you should not trust a third party not to snoop your DNS queries (I care so much about that that I now actually encrypt all my DNS queries using DNS over TLS) Encrypted queries are fine but don't stop the DNS provider logging them. I want to choose my DNS provider and not have it dictated by any VPN connection I may be using.

...

And whilst it is your choice I admit, personally I would be /very/ bothered if anyone connecting to my protected network were using a desktop which was also used to browse "bigandbusty-dot-com" (or any other such sites). The potential for them to be malware ridden is obvious. Don't your customers care? If they're using such domains and have access to my VPN, it's unlikely that the issue is DNS related and I should assume that these things happen and limit the impact as far as possible at my office network end; malware on a client PC is an ever-present risk and I don't think logging the fact that someone has visited bigandbusty-dot-com adds much to the party. Indeed the majority of malware I've had to deal with in the past comes from infected legitimate sites, but that probably says more about the people I work with than its prevalence on adult sites.

My point is that if I am accepting the idea of individuals accessing the office VPN with their own devices I cannot expect to be privy to the sites they access on their device. If you don't like the example I gave, I'm sure you can come up with other DNS query examples that someone might make which you don't think I have any right to know about - you wouldn't be worried about the secrecy of your own DNS queries otherwise, of-course.

Since I'm not logging DNS queries anyway it's somewhat moot, but certainly I do not think that my own DNS queries should routinely be accessible to the administrator of any third party VPN I have reason to connect to.

...

Whatever, you seem to have solved your original problem with openwrt, so the discussion is now somewhat moot. Moot, certainly, but interesting nevertheless (at least to me).

On Fri, Oct 02, 2020 at 09:29:08AM +0100, Mark Rogers wrote:

via Google. (For example, it never crossed my mind to refer to the addresses as RFC1918, and I would certainly never have used the word "rebind" - and still don't really understand its usage here even now.)

The choice of the word rebind comes from here: https://crypto.stanford.edu/dns/dns-rebinding.pdf Adam -- fubar

On Thu, Oct 01, 2020 at 03:10:38PM +0100, Huge wrote:

Whilst I see what you're doing, and indeed I do similar things, you're trying to route RFC1918 addresses, so it's not hugely surprising odd things happen.

There's nothing inherently weird or wrong about routing RFC1918 address space. Adam --

On Fri, 2 Oct 2020 at 16:15, Huge <huge@huge.org.uk> wrote:

Perhaps you should read the RFC.

I think the relevant paragraphs are: Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. As this RFC predates RFC2119 it's not clear how words like "should" vs "shall" are meant, but assuming the terminology of RFC2119 (which I think was common at the time if not formalised) I take the above to mean that traffic for RFC1918 hosts MUST NOT leave the local network, but that things like DNS records are only recommended not to leave the enterprise, which gives (to me, anyway) some leeway for cases where doing so makes sense but it shouldn't be the norm. It therefore feels right to me that dnsmasq should block RFC1918 addresses from outside the network by default but to have a mechanism to whitelist domains where required. (I presume that is why the whitelist function exists: it would be an odd thing to add if using it was always wrong.) The more interesting aspect for me is following the whack-a-mole trail that got us here: defeating XSS attacks by enforcing same host policies => exploit DNS to make two hosts look like the same host. It seems odd that the reason it is needed is that browser plugins don't use the browser DNS resolution tables thus making it possible for a plugin to get a different DNS result from the browser for the same host at (close enough to) the same time. Is there a reason why browser plugin DNS queries are independent of the browser itself? -- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER

On Fri, Oct 02, 2020 at 04:14:53PM +0100, Huge wrote:

Perhaps you should read the RFC.

I have, it appears that maybe you don't understand it, section 3 explains it quite clearly: "An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space so they may communicate with each other in their own private internet" Which part of that RFC says you should not route the address space? It's not globally routable but exists so that people can create their own private internet, to do that it would need to be routable. Adam --