This DNS over HTTP thing

Mon Oct 7 18:47:15 UTC 2019

So a malicious or rogue DNS operator... 1.1.1.1 or 8.8.8.8 is going to tell your application to use the locally configured DNS for domain lookups rather give an normal response? Not sure how this malice would really affect you as your local DNS should be functional. The idea to make DoH and DoT, or even unencrypted DNS with external DNS servers play nicely with environments that require internal users to local DNS for local domains.

The point is having a record to tell severs like 1.1.1.1 and 8.8.8.8 when they should not respond normally to specific clients from a specific source for specific domains.

You will always have malicious cases and scenarios, but a browser configured to use DoH or Dot to 1.1.1.1 and 8.8.8.8, I do not see how they would be affected when they do use DNSSEC.

Worst case would a user configured network DNS manually rather than using DHCP, but still they would be broken as the would be getting a non-working external address for a local server.

Thank you,

Kevin McCormick

-----Original Message-----
From: Jim <mysidia at gmail.com> 
Sent: Monday, October 7, 2019 12:45 PM
To: Kevin McCormick <kmccormick at mdtc.net>
Cc: Brandon Martin <lists.nanog at monmotha.net>; nanog at nanog.org
Subject: Re: This DNS over HTTP thing

On Mon, Oct 7, 2019 at 11:44 AM Kevin McCormick <kmccormick at mdtc.net> wrote:
>
> If the DNS request comes from an IP in matching a CIDR network address in the ULS record, then the server would respond with an error message telling the application to use the configured local DNS server.

All if this is ultimately falsifiable by a malicious or rogue DNS operator.

My suggestion would be ultimately that DNS Clients implement DNSSEC validation themself to avoid tampering by a malicious client on their network for phishing purposes or a malicious recursive DNS Resolver server ---  Such a DNS proxy service in a home router corrupted by malware that modifies DNS resposes for an attacker,  or  those rogue DNS servers of ISPs that typically sometimes replace NXDOMAIN replies with A records attempting to collect typo queries for advertising or that redirect A records to other hosts designed to intercept and monitor or proxy traffic with advertisements inserted.

A secure administrative selection of local DNS server could be supported by allowing a TXT record to be placed in the reverse DNS zone for the IP address which is the IP address configured on the client's IP network interface alongside PTR records.

The client software would then be required to perform a DNSSEC signature check to ensure that the reverse DNS zone is signed and has the proper chain of signed DS records ultimately coming from the IP6.ARPA  or IN-ADDR.ARPA zone.

*
Clients using RFC1918 IP addresses would not be able to support this;  Because, there is no way of  establishing WHO is authorized to sign locally on behalf of the "operator" of a RFC1918 or link-local IP address...

The latter seems more like a system administration problem however --

The DHCP software running on a client ought to have some way of indicating whether the network being connected to is  Secure and "Managed" by the same entity that owns and configures the client device:

I.E.  Same company manages the LAN and the entire path up to recursive
DNS servers are secure,    Or whether the PC is owned and managed by
different entities --  such as a  mobile PC user connected to someone else's network, or a Home user connected to their own ISP,  and the network is, therefore, untrusted.

(Untrusted in the sense that DNS Servers are controlled by a 3rd party who is not the owner or operator of the personal computer or client device which is connecting for the supposed purpose of accessing the public internet  --- therefore no legitimate authority exists for having clients tolerate tampering with private traffic between that device and another internet host, content in DNS or other IP traffic content, and so on)

> Thoughts?
> Thank you,
> Kevin McCormick
--
-JH