dnssec-analyzer.verisignlabs.com aaaa lookup fail

2024-04-26 Thread Lee 
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 failed
(failure) for dnssec-analyzer.verisignlabs.com/IN/ at query.c:7471


Is that because of the insecure delegation shown at
  https://dnsviz.net/d/dnssec-analyzer.verisignlabs.com/dnssec/
and me having "dnssec-validation auto;" in named.conf?

Thanks
Lee

(still struggling to understand this stuff)
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about resolver

2024-04-26 Thread Josh Kuo 
>
> 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. Reverse-mapping zones work the same as forward-mapping zones,
they also need to be delegated properly.

If you prefer a more visual output, try DNSViz:
https://dnsviz.net/d/180.96.34.in-addr.arpa/dnssec/
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about resolver

2024-04-26 Thread Mark Andrews 
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.  

Named was looking up theses NS records I.e. chasing the DS servers.   This can 
result in named finding delegation errors.  QNAME minimisation also exposes 
these errors as it also does NS queries.  Garbage in breakage out. 
-- 
Mark Andrews

> On 27 Apr 2024, at 00:45, J Doe  wrote:
> 
> 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 record between the
>> child and the parent (security lameness).
>> 
>> You can use tools such as
>> https://dnssec-analyzer.verisignlabs.com/online
>>  to help you analyze
>> further. If you need to refresh your knowledge on how DNSSEC works, see
>> the ISC DNSSEC Guide:
>> https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html
>> 
>> 
>> -Josh
> 
> Hi Josh,
> 
> Thank you for your prompt reply!
> 
> In this particular case, isn't the resolver attempting to do a reverse
> lookup of the IP address that's listed ?
> 
> Secondly, I'm still not entirely sure what the phrasing "chase DS
> servers" means.  I am aware of the DS RR type.
> 
> As a side-note:  I believe the "lame-servers" here is a function of me
> configuring QNAME minimization to "relaxed".
> 
> Thanks,
> 
> - J
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace

2024-04-26 Thread Havard Eidnes via bind-users 
> 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.

>   * Below the zone cut the nameserver claims to be authoritative for its
> parent's zone (191.131.in-addr.arpa) instead of
> 85.191.131.in-addr.arpa. (In other words it's lame.)

Well, yes.  When queried for the NS set for 85.191.131.in-addr.arpa it
returns "NOERROR" with the 191.131.in-addr.arpa SOA record in the
authority section.  This is what is called an "upward referral", and
indicates that the delegation structure and/or child name server setup
is inconsistent with the delegation structure.  Were I less charitable
I would say "messed up".  Basically what you say above -- it doesn't
serve the delegated zone so is "lame".

>   * (Below the zone cut it also erroneously advertises one of its
> nameservers as simply ns102. instead of ns102.click-network.com)

Yep.

>   * There is no server which actually advertises itself as authoritative
> for 85.191.131.in-addr.arpa

Yep.  Both of the resolveable NSes ns102.click-network.com and
fs838.click-network.com claim authority over 191.131.in-addr.arpa,
which they don't have according to the parent zone DNS delegations.

Regards,

- Håvard
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace

2024-04-26 Thread Sten Carlsen 
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-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 address for 'ns102.click-network.com': not found
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
> this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



signature.asc
Description: Message signed with OpenPGP
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace

2024-04-26 Thread Fred Morris 
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.

The facts are:

  * 191.131.in-addr.arpa is served from awsdns
  * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com
and ns102.click-network.com above the zone cut.
  * Below the zone cut the nameserver claims to be authoritative for its
parent's zone (191.131.in-addr.arpa) instead of
85.191.131.in-addr.arpa. (In other words it's lame.)
  * (Below the zone cut it also erroneously advertises one of its
nameservers as simply ns102. instead of ns102.click-network.com)
  * There is no server which actually advertises itself as authoritative
for 85.191.131.in-addr.arpa

9.18.21 with "qname-minimization disabled; minimal-responses no;":

; <<>> DiG 9.18.21 <<>> @127.0.0.1 -x 131.191.85.31
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45088
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1420
; COOKIE: 95f68497698c23e20100662bd448c6b1f33814567a34 (good)
;; QUESTION SECTION:
;31.85.191.131.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
31.85.191.131.in-addr.arpa. 604800 IN   PTR flame.m3047.net.

;; AUTHORITY SECTION:
85.191.131.in-addr.arpa. 1799   IN  NS  ns102.click-network.com.
85.191.131.in-addr.arpa. 1799   IN  NS  fs838.click-network.com.

;; ADDITIONAL SECTION:
fs838.click-network.com. 172799 IN  A   131.191.7.194
ns102.click-network.com. 172799 IN  A   131.191.7.12

;; Query time: 1620 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Apr 26 09:20:24 PDT 2024
;; MSG SIZE  rcvd: 201

9.12.3 offering two different responses:

; <<>> DiG 9.12.3-P1 <<>> -x 131.191.85.31
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20212
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
; COOKIE: 22623b3f260659f6699dc2ae662bcf96945739b2062b578d (good)
;; QUESTION SECTION:
;31.85.191.131.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
31.85.191.131.in-addr.arpa. 183024 IN   PTR flame.m3047.net.

;; AUTHORITY SECTION:
191.131.in-addr.arpa.   49595   IN  NS  ns-986.awsdns-59.net.
191.131.in-addr.arpa.   49595   IN  NS  ns-7.awsdns-00.com.
191.131.in-addr.arpa.   49595   IN  NS  ns-1603.awsdns-08.co.uk.
191.131.in-addr.arpa.   49595   IN  NS  ns-1165.awsdns-17.org.

;; ADDITIONAL SECTION:
ns-7.awsdns-00.com. 106009  IN  A   205.251.192.7
ns-986.awsdns-59.net.   110789  IN  A   205.251.195.218
ns-1165.awsdns-17.org.  110789  IN  A   205.251.196.141
ns-1603.awsdns-08.co.uk. 110789 IN  A   205.251.198.67

;; Query time: 1 msec
;; SERVER: 10.0.0.220#53(10.0.0.220)
;; WHEN: Fri Apr 26 09:00:22 PDT 2024
;; MSG SIZE  rcvd: 334



; <<>> DiG 9.12.3-P1 <<>> -x 131.191.85.31
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42172
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
; COOKIE: 166de4c8b3f9b189d0aad8b9662bd608135dc2782eb1138a (good)
;; QUESTION SECTION:
;31.85.191.131.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
31.85.191.131.in-addr.arpa. 181374 IN   PTR flame.m3047.net.

;; AUTHORITY SECTION:
85.191.131.in-addr.arpa. 1794   IN  NS  ns102.click-network.com.
85.191.131.in-addr.arpa. 1794   IN  NS  fs838.click-network.com.

;; ADDITIONAL SECTION:
fs838.click-network.com. 294IN  A   131.191.7.194
ns102.click-network.com. 294IN  A   131.191.7.12

;; Query time: 1 msec
;; SERVER: 10.0.0.220#53(10.0.0.220)
;; WHEN: Fri Apr 26 09:27:52 PDT 2024
;; MSG SIZE  rcvd: 201

Housekeeping: the version of DiG above also changes, but this is not
simply the version of dig:

# dig @127.0.0.1 version.bind ch txt +short
"9.18.21"
# dig version.bind ch txt +short
"9.12.3-P1"

There are other oddities, for instance the actual authoritative TTL for
the nameservers appears to be 300 not 172799:

# rndc flush
# dig @127.0.0.1 click-network.com ns

; <<>> DiG 9.18.21 <<>> @127.0.0.1 click-network.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6461
;; flags: qr rd ra; QUERY:

Re: Question about resolver

2024-04-26 Thread J Doe 

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 record between the
child and the parent (security lameness).

You can use tools such as
https://dnssec-analyzer.verisignlabs.com/online
 to help you analyze
further. If you need to refresh your knowledge on how DNSSEC works, see
the ISC DNSSEC Guide:
https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html


-Josh


Hi Josh,

Thank you for your prompt reply!

In this particular case, isn't the resolver attempting to do a reverse
lookup of the IP address that's listed ?

Secondly, I'm still not entirely sure what the phrasing "chase DS
servers" means.  I am aware of the DS RR type.

As a side-note:  I believe the "lame-servers" here is a function of me
configuring QNAME minimization to "relaxed".

Thanks,

- J
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users