> The facts are:
>
> * 191.131.in-addr.arpa is served from awsdns
Correct. And it's delegated to from the 131.in-addr.arpa zone,
maintained by ARIN.
> * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com
> and ns102.click-network.com above the zone cut.
Correct.
> * Be
Trace from my location dies even earlier:
;; Received 915 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 17 ms
;; connection timed out; no servers could be reached
Again just a data point.
> On 24 Apr 2024, at 22.03, tale via bind-users
> wrote:
>
> Hmm, I wonder if qname-minimisat
As further data points with BIND as a caching / recursive sometimes it
"works" and provides inconsistent AUTHORITY, although anecdata suggests
this is more prevalent with older versions of BIND. In one case BIND
9.12 reports the AUTHORITY as the parent zone in fact, with the parent's
nameservers.
They've got a number of problems. click-network.com is one of them.
https://dnsviz.net/d/click-network.com/dnssec/
There is some backstory. The City of Tacoma used to run broadband,
and that was Click! Network. The origin story is that this had something
to do with SCADA or power distribut
Hmm, I wonder if qname-minimisation is at issue here. My trace dies with:
85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com.
85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com.
couldn't get address for 'fs838.click-network.com': not found
couldn't get a
While BIND 9.18.21 with "qname-minimization strict;" SERVFAILs on the
following query, dig with +trace resolves it. Just a data point, and if
they fix their s**t and stop impersonating a signed zone then presumably
the example will resolve itself (pun intended).
dig -x 131.191.85.31
dig -x 131.19
6 matches
Mail list logo
