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 <mysi...@gmail.com> 
Sent: Monday, October 7, 2019 12:45 PM
To: Kevin McCormick <kmccorm...@mdtc.net>
Cc: Brandon Martin <lists.na...@monmotha.net>; nanog@nanog.org
Subject: Re: This DNS over HTTP thing

On Mon, Oct 7, 2019 at 11:44 AM Kevin McCormick <kmccorm...@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

Reply via email to