DNS resolve on server side - not browser

[Ciacho]

Feature Description

Please add the functionality of checking the IP address (resolve domain) from the server / application level, not from the browser level.

Some customers have enabled blocking such as "Anonizers" in the corporate network (cloudflare-dns.com and dns.google come under this category) - and the browser cannot get the IP address.

Is your feature request related to a problem? Please describe.

The browser cannot retrieve A / AAA entries for domains via the API because the client's network security policies block such connections.

Environment & Use Case

Hyperglass 1.0.4
Client OS: WIndows 10, Windows 11, MacOS 12.0.1
Browser: Firefox, Safari, Edge
Security on desktop: Cisco Umbrella

Additional Context

[thatmattlove]

Just to clarify, are you requesting that client-side DNS resolution be completely deprecated in favor of a server-side solution, or just the option to configure it according to the way you want it?

If the latter, it's probably doable as long as you're aware of the implications, which would be that the user would be doing lookups to destinations from the perspective of the hyperglass server, which in many cases isn't going to be what they're looking for. For example, the user may be wanting to "ping www.google.com" from three of your routers. With the current behavior (setting aside client browser blocking), your three routers would look up what the user resolves www.google.com to, which is more likely to be what the user is looking for, rather than what your hyperglass server resolves www.google.com to (which could be in a completely different location than the user, or the three routers).

There are obviously arguments to be made for both directions, I just wanted to clarify what you were asking for so I can respond/implement accordingly.

Thanks,
Matt

[Ciacho]

I am aware of the differences in indications of IP addresses for A/AAAA inquiries, but since I have been contacted by clients whose network administrators block the connection to 'Anomyzers', it may well affect a larger group of users :)

Therefore, I would like to be able to configure - the standard behavior, i.e. the browser checks the DNS entry or the option that dns is checked on the server side with the application.

Unless it is much easier to do a mix of two options - the browser checks A/AAAA, if there is a communication error to the dns-cloudflare/dns.google API then it is checked on the application server side and if it also gets NXDOMAIN here, then the error message saying that the entered the domain is invalid (but I don't know if it is possible/how time-consuming it would be to implement it) ;)

[thatmattlove]

I'm thinking the approach should be a configuration flag with three options:

1. Client (current functionality of client-side DNS-over-HTTPS)
2. Server (server resolves hostname)
3. Client Then Server (client is tried first, and server is tried if the client fails)

An example in YAML config form could be:

dns:
  provider: google|cloudflare
  mode: client|server|client-then-server

However, I have some concerns, and some questions (from both you and anyone in the community who would like to comment):

We're using DNS over HTTPS in the client today, which inherently queries public resolvers, so there's no possibility of exposing internally resolvable (by hyperglass) DNS records to end users. With server-side DNS resolution, this is something we need to consider. If, for example, we simply use native DNS resolution, hyperglass could be used as a discovery vector for an attacker to learn of valid internal (not publicly resolvable) DNS records for use in a separate attack.

With that concern in mind, I would lean towards implementing DNS over HTTPS for the server side as well. On the flip side, I can easily see instances where users might want DNS queries to be internally resolvable, for instances where hyperglass is used as an internal tool. So, does that mean we have two options, with one (DNS over HTTP, I would think) as a default? As a footnote to this concern, while it's not a dealbreaker, it is worth noting that this would introduce two new APIs to the codebase which would need to be implemented, maintained, and tested, and would go unused by default. So then, our config might look like:

dns:
  provider: google|cloudflare
  mode: client|server|client-then-server
  server_resolution_method: dns-over-http|native

Another consideration is input validation. In v2, a new Directive API is introduced that replaces the current concepts of "commands" in v1. Contained within a directive is the command (or commands) to execute in order to get the desired output, as well as customizable input validation rules, ability to define plugins (also a new concept in v2), and customizable display text for the UI. During the input validation phase, the query target is run through any configured rules (and/or plugins), and if it passes, the query is allowed. With server-side DNS resolution, how would we perform validation? Based on hostname queried, or the IP address to which a hostname resolves? I can easily see use cases for both, so I'm not sure there's a right answer. This is where it'd be great to get some outside feedback.

Finally, I'm not certain how I feel about the UX of 3 above — the 'Client then Server' approach. For instance, if the user supplies a hostname and the client-side resolution fails because of a browser plugin or network-level firewall, do we tell them? Why or why not? If we don't tell them, what's the experience like? I'm imagining a spinner being displayed for no apparent reason and then disappearing for no apparent reason in the event of a failure. I'm open to input on how anyone thinks this should work.

I hope this doesn't sound like I'm opposed to the request — I'm not — but I do want to thoughtfully consider how to implement it in the best way, particularly as it relates to security and UX.

Thanks!
Matt

[blkmajik]

It has always been my experience that when using a looking glass server I 100% wanted everything from the servers perspective. I can get the client side information from the client itself (nslookup in this case).

Typically when diagnosing problems I use multiple looking glass servers and the varying server side perspective is important.

Most (all?) current generation operating systems are capable of handling DoH as well as traditional DNS lookups using system provided handlers. The sysadmin for the system can determine what they want to do for the whole system. This application should use the system configuration for server side lookups. Now I do think it's important to note that this could lead to internal DNS leaks within the documentation.

If the sysadmin wants a different DNS setting for this application only, well that's what Docker is for.