dig dnssec-analyzer.verisignlabs.com
gives me a SERVFAIL & this in the bind errors_log file:
$ grep dnssec-analyzer.verisignlabs.com named-errors.log | tail -1
26-Apr-2024 19:28:37.600 query-errors: info: client @0x7f384488e3c0
127.0.0.1#47121 (dnssec-analyzer.verisignlabs.com): query
>
> In this particular case, isn't the resolver attempting to do a reverse
> lookup of the IP address that's listed ?
>
>
You are right, I missed that this is a reverse-mapping zone. In that case,
run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa" and you'll see
the problem.
DS records live in the parent zone and the RFC 1034 rules for serving zone
break down when a grandparent zone and child zone are served by the same
server. This is corrected be the client by looking for intermediate NS records
to find the hidden delegations then resuming the DS lookup.
> 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.
> *
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
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.
On 2024-04-25 08:55, Josh Kuo wrote:
DS = Delegation Signer, it is the record type that a signed child upload
to the parent zone. It's difficult to say for sure without more
information such as which domain name you are trying to resolve, but
looks like it is probably due to a mis-matching DS
7 matches
Mail list logo
