6 ms·

It's still not clear to me how this will work in internal networks. AFAIK it's not possible to distribute internal DoH servers via DHCP, and it seems orthagonal

It's still not clear to me how this will work in internal networks. AFAIK it's not possible to distribute internal DoH servers via DHCP, and it seems orthagonal to the goals of DoH since "cafe wifi" could give you dodgy servers. But how do I as a network administrator with internal DNS domains serve my users? Maybe browsers and OSs could look at the local search domain, and send queries matching to DHCP servers, and everything else over DoH, kinda like split dns with a VPN?

BillinghamJ 8y ago
Serve the internal IPs from public hostname DNS records? Internal DNS I think is largely not a good thing and I'd be happy to see it go.
- Aissen 8y ago
  Could you develop ? You think you should answer with internal IPs with external DNS records and everything is addressed at the routing level ?
  - zimbatm 8y ago
    The DNS zone would be public and tied to a real domain. So both private and public clients would be able to query Eg: ci.myorg-int.com -> 10.11.12.13 One advantage of such method is that it is possible to re-use the public CA infrastructure to provision services with TLS certificated. It also means that services can easily be migrated to public IPs once they are secured on the endpoint. The downside is that now all the internal services are discoverable using DNS scanning techniques. It means that competitors can see what services the organisation is using. Or attackers can better prepare themselves for infiltration. Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. For example and attacker can trick your browser in requesting a resource from xxx.somedomain.com that points to 10.11.12.13. If the CI is vulnerable to CSRF then the attacker can use the browser to exfiltrate information or do some actions on the CI.
    - megous 8y ago
      > Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. Your web server should be configured to not serve content just by IP and require Host header to be a domain you control. (like using server_name in nginx) Otherwise they can just point to 10.11.12.13 directly anyway.
      - X-Istence 8y ago
        Sure, the web server SHOULD... but what if it is misconfigured? Or doesn't have an option to properly validate the Host header? This is an internal client using an internal IP address to communicate with an internal service... just so happens that a malicious user made the internal client talk to it maliciously. DNS rebinding attacks being stopped by the resolver are a great place to start and something we can do. Bypassing that protection in the name of resolving using DoH just means you've made things less secure.
        megous 8y ago
        I agree. I think DoH should be put on the edge of the network, using something like dnscrypt-proxy. I don't think it should be put in the browser. It would actually made my setup less private, since I use DoH over tor. Though configuring the http servers (like printers or whatever) and/or putting them behind a proxy on a sparate network, if they are sensitive/not configurable, should be done too.
      - dsl 8y ago
        > Your web server should be configured I think you underestimate the number of things on your network that run unconfigurable web servers.
    - amaccuish 8y ago
      DNSMASQ lets you luckily whitelist certain domains from dns rebinding protection (like Plex, which relies on resolving to internal IPs). I'm still not comfortable exposing internal network details to the internet however.
- kenny_r 8y ago
  As a sysadmin I disagree strongly. Being able to host my own authoritative servers for my domains inside my org is a fantastic feature of DNS. It lets me do things like split-horizon, which lets me deal with clients coming from different origins that may reach certain servers with or without NAT. I'm also not keen on putting all my records on public name servers, for everyone to discover.
  - BillinghamJ 8y ago
    You could run your own DNS server. As long as you can get the relevant TLS cert, it doesn't even need to be public. You just would need to accept DOH connections
- amaccuish 8y ago
  First thing that comes to mind with this idea is that Active Directory is going to be around for a long while yet. Second, my network filters DNS rebinding, expect from plex.com. I guess I could ad my domain to it, but that's an extra point of failure.
bluejekyll 8y ago
Isn’t this a resolver configuration issue on the client? The browsers are not respecting DHCP in this case, but that doesn’t mean that other resolvers can’t be configured via DHCP to try DoH or DoT.
protomyth 8y ago
"everything else over DoH" I have local DNS servers set to resolve both our intranet and all external queries. Some external queries are blocked for various reason. Either a browser uses the local network settings or it gets banned from the network. This is not a discussion because the real world intrudes on what browser vendors think is best.
- zamadatix 8y ago
  Implicit proxying and inspection has always been a farce when it comes to "locking down clients". If you want to control traffic to clients you operate you should do it as an explicit proxy. If you want to control traffic to clients you don't operate it's not actually possible to both respect the client and inspect the traffic enough to meet security goals. This tradeoff has always been true but everyone settled on the "good enough" that means security isn't actually strong, clients aren't actually treated as internal or external, and protocols are ossified because the FW expects wxyz to implement the above two failures.
  - protomyth 8y ago
    We don't want Google or Mozilla to have a running list of our users DNS requests. We don't want Google or Mozilla to have a list of our internal servers. They are browsers and can use the same network stack as any other program. I have other types of filtering, but the whole idea of a browser ignoring internal services is going to get it banned.
    - dagenix 8y ago
      It sounds like you will have to ban all browsers on whatever network you manage.
      - protomyth 8y ago
        Why would I have to ban all browsers? Why would anyone accept Google or Mozilla knowing all the sites they visit?
deleted 8y ago
[deleted]
devman0 8y ago
I think its going to come down to smart network management in the client OS. If I'm on a trusted network, use the network resolvers (either via UDP 53 or DoH, or whatever) and if I'm not use preconfigured resolvers like 1.1.1.1 or something, part of not trusting the network should also be not trusting the resolver. Before DoH this was a moot point since UDP 53 can be trivially captured and redirected, now the client OS can actually do something about it. I don't like the idea of individual applications overriding system resolver settings.
bugmen0t 8y ago
If you're the admin, you can disable DoH through a group policy, no?
- LinuxBender 8y ago
  No. Well, not for shops that have non windows. In the bay area, it is quite common to have a mix of Windows, Mac and some Linux. We are 60+% Mac.
josteink 8y ago
> AFAIK it's not possible to distribute internal DoH servers via DHCP Back in the days we used to call this DHCP option 6, i.e. DNS. I'm not sure why you want to replace a DHCP provided DNS server with a DHCP provided DoH server. Because why on earth would the DHCP-server provide different DNS-servers for those two use-cases? The idea itself makes no sense. Can we please just get back to regular DNS, please? It works. It scales. It's possibly the single last thing on the internet which is still decentralized, and I'd hate to see this become another centralized, single point of failure, walled-garden bullshit.
- isostatic 8y ago
  I assume you agree on the need for securing DNS (DNS over TLS for example). Just watched a UKNOF presentation on DNS changes. Sounds like google/mozilla were fed up with the sluggishness of standards bodies, network operators, and OSes in securing DNS, so have gone for their own version. Charitably I'd like to think that this is a wakeup call from Mozilla, "sort out your shit or this is the future, but with google owning it"

BillinghamJ 8y ago

Serve the internal IPs from public hostname DNS records? Internal DNS I think is largely not a good thing and I'd be happy to see it go.

Aissen 8y ago
Could you develop ? You think you should answer with internal IPs with external DNS records and everything is addressed at the routing level ?
- zimbatm 8y ago
  The DNS zone would be public and tied to a real domain. So both private and public clients would be able to query Eg: ci.myorg-int.com -> 10.11.12.13 One advantage of such method is that it is possible to re-use the public CA infrastructure to provision services with TLS certificated. It also means that services can easily be migrated to public IPs once they are secured on the endpoint. The downside is that now all the internal services are discoverable using DNS scanning techniques. It means that competitors can see what services the organisation is using. Or attackers can better prepare themselves for infiltration. Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. For example and attacker can trick your browser in requesting a resource from xxx.somedomain.com that points to 10.11.12.13. If the CI is vulnerable to CSRF then the attacker can use the browser to exfiltrate information or do some actions on the CI.
  - megous 8y ago
    > Another downside of DoH is that it's not possible to filter out DNS rebinding attacks. Your web server should be configured to not serve content just by IP and require Host header to be a domain you control. (like using server_name in nginx) Otherwise they can just point to 10.11.12.13 directly anyway.
    - X-Istence 8y ago
      Sure, the web server SHOULD... but what if it is misconfigured? Or doesn't have an option to properly validate the Host header? This is an internal client using an internal IP address to communicate with an internal service... just so happens that a malicious user made the internal client talk to it maliciously. DNS rebinding attacks being stopped by the resolver are a great place to start and something we can do. Bypassing that protection in the name of resolving using DoH just means you've made things less secure.
      - megous 8y ago
        I agree. I think DoH should be put on the edge of the network, using something like dnscrypt-proxy. I don't think it should be put in the browser. It would actually made my setup less private, since I use DoH over tor. Though configuring the http servers (like printers or whatever) and/or putting them behind a proxy on a sparate network, if they are sensitive/not configurable, should be done too.
    - dsl 8y ago
      > Your web server should be configured I think you underestimate the number of things on your network that run unconfigurable web servers.
  - amaccuish 8y ago
    DNSMASQ lets you luckily whitelist certain domains from dns rebinding protection (like Plex, which relies on resolving to internal IPs). I'm still not comfortable exposing internal network details to the internet however.
kenny_r 8y ago
As a sysadmin I disagree strongly. Being able to host my own authoritative servers for my domains inside my org is a fantastic feature of DNS. It lets me do things like split-horizon, which lets me deal with clients coming from different origins that may reach certain servers with or without NAT. I'm also not keen on putting all my records on public name servers, for everyone to discover.
- BillinghamJ 8y ago
  You could run your own DNS server. As long as you can get the relevant TLS cert, it doesn't even need to be public. You just would need to accept DOH connections
amaccuish 8y ago
First thing that comes to mind with this idea is that Active Directory is going to be around for a long while yet. Second, my network filters DNS rebinding, expect from plex.com. I guess I could ad my domain to it, but that's an extra point of failure.

bluejekyll 8y ago

Isn’t this a resolver configuration issue on the client? The browsers are not respecting DHCP in this case, but that doesn’t mean that other resolvers can’t be configured via DHCP to try DoH or DoT.

protomyth 8y ago

"everything else over DoH" I have local DNS servers set to resolve both our intranet and all external queries. Some external queries are blocked for various reason. Either a browser uses the local network settings or it gets banned from the network. This is not a discussion because the real world intrudes on what browser vendors think is best.

zamadatix 8y ago
Implicit proxying and inspection has always been a farce when it comes to "locking down clients". If you want to control traffic to clients you operate you should do it as an explicit proxy. If you want to control traffic to clients you don't operate it's not actually possible to both respect the client and inspect the traffic enough to meet security goals. This tradeoff has always been true but everyone settled on the "good enough" that means security isn't actually strong, clients aren't actually treated as internal or external, and protocols are ossified because the FW expects wxyz to implement the above two failures.
- protomyth 8y ago
  We don't want Google or Mozilla to have a running list of our users DNS requests. We don't want Google or Mozilla to have a list of our internal servers. They are browsers and can use the same network stack as any other program. I have other types of filtering, but the whole idea of a browser ignoring internal services is going to get it banned.
  - dagenix 8y ago
    It sounds like you will have to ban all browsers on whatever network you manage.
    - protomyth 8y ago
      Why would I have to ban all browsers? Why would anyone accept Google or Mozilla knowing all the sites they visit?

deleted 8y ago

[deleted]

devman0 8y ago

I think its going to come down to smart network management in the client OS. If I'm on a trusted network, use the network resolvers (either via UDP 53 or DoH, or whatever) and if I'm not use preconfigured resolvers like 1.1.1.1 or something, part of not trusting the network should also be not trusting the resolver. Before DoH this was a moot point since UDP 53 can be trivially captured and redirected, now the client OS can actually do something about it. I don't like the idea of individual applications overriding system resolver settings.

bugmen0t 8y ago

If you're the admin, you can disable DoH through a group policy, no?

LinuxBender 8y ago
No. Well, not for shops that have non windows. In the bay area, it is quite common to have a mix of Windows, Mac and some Linux. We are 60+% Mac.

josteink 8y ago

> AFAIK it's not possible to distribute internal DoH servers via DHCP Back in the days we used to call this DHCP option 6, i.e. DNS. I'm not sure why you want to replace a DHCP provided DNS server with a DHCP provided DoH server. Because why on earth would the DHCP-server provide different DNS-servers for those two use-cases? The idea itself makes no sense. Can we please just get back to regular DNS, please? It works. It scales. It's possibly the single last thing on the internet which is still decentralized, and I'd hate to see this become another centralized, single point of failure, walled-garden bullshit.

isostatic 8y ago
I assume you agree on the need for securing DNS (DNS over TLS for example). Just watched a UKNOF presentation on DNS changes. Sounds like google/mozilla were fed up with the sluggishness of standards bodies, network operators, and OSes in securing DNS, so have gone for their own version. Charitably I'd like to think that this is a wakeup call from Mozilla, "sort out your shit or this is the future, but with google owning it"