Subject: [Add] DEER and CPE resolvers

From: Ray Bellis <[email-masked]>
Date: Mon, 16 Nov 2020 08:17:51 +0000

You may find some useful background here.

I did a lot of research into the behaviour of CPE "resolvers" back in
2008 or so, which led to RFC 5625 and SSAC035.

<https://www.icann.org/en/system/files/files/sac-035-en.pdf>

Many of the CPE resolvers are just dumb forwarders little better than an
AGL.  Most don't even support DNS over TCP, and they often have
significant other flaws in their DNS compatibility (e.g. no support for
EDNS).

I did also write a draft which is somewhat similar to DEER, albeit it
was constrained to only return IPv4 or IPv6 addresses for a resolver.
It was intended to support the case (as Martin just alluded to in the WG
session) where the "dumb DNS proxy" just forwards the query for a
special-use domain to the network-provided upstream resolver.

draft-bellis-dns-recursive-discovery-00

Ray

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Nov 2020 09:34:51 -0500

> 2008 or so, which led to RFC 5625 and SSAC035.

That's a long time ago, even by trailing-edge shippers of openwrt.
I wonder if we redo your survey using Atlas probes: I worry that in most
cases the probes are self-selected into homes of clueful people though.

    > significant other flaws in their DNS compatibility (e.g. no support for

dnsmasq of 2020 (or even 2015) is much better.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ray Bellis <[email-masked]>
Date: Thu, 19 Nov 2020 16:30:24 +0000

> That's a long time ago, even by trailing-edge shippers of openwrt.

Yes, it was a long time ago, but routers don't get replaced very often.

In any event, it was the systems running bespoke embedded OS's that were
the biggest problem.   I didn't test OpenWRT but I expect it would have
faired pretty well.

> cases the probes are self-selected into homes of clueful people though.

Without being able to automatically detect the model of CPE it's
probably not so useful.

The "dig" commands we used are all in the SAC035 paper, though, should
anyone want to try to replicate the tests.

> dnsmasq of 2020 (or even 2015) is much better.

Even in 2008 dnsmasq coped somewhat better than those CPEs running
non-Linux kernels.

Unlike many other CPE DNS stacks dnsmasq is at least a proper DNS
forwarder, rather than a dumb ALG-like UDP proxy.   The author also
responded quickly to those flaws I did find.

Ray