In a DOCSIS network, for whatever that's worth, the link from the home (cable
modem) to the next hop (CMTS) is encrypted. It is then usually just one or two
hops within the ISP's regional network to the recursive DNS (in some cases
DNSSEC-validating, as in our case). So I suppose that the threat model in this
example is presumably someone (1) eavesdropping on the relatively short path
between CMTS and resolver or (2) modifying non-DNSSEC-validated responses - and
that's does not seem like a very high risk threat IMO, given all the other
potential and real threats lurking around on the Internet.
In any case, if a user felt it was a high risk then letting their stub pick up
the same resolver address (such as via DHCP) and choose to use TLS to secure
the DNS query stream to the same resolvers would seem like an easy solution.
But I am sure there are countries where this might carry a higher risk, in
which case users have traditionally used Tor, VPNs, etc. In the latter
(user-directed) case this suggests an implementation model where an end user
optionally turns something on rather than a 3rd party deciding it should always
be on (given the likely downsides of this operationally).
- Jason
On 8/18/18, 8:54 PM, "DNSOP on behalf of Paul Vixie" <dnsop-boun...@ietf.org
on behalf of p...@redbarn.org> wrote:
my threat model is intruders or eavesdroppers on the path between me and
my rdns. i'd like the dhcp announcement to include a tcp/853 signal
along with a pre-shared key or the hash thereof. the benefit would be
that if my rdns network path is less secure than my dhcp network path,
i'll improve the former by not using traditional udp/53. does that help?
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
