Bind forwarding doesn't goes right if using views

I have two server with Bind installed. One is a public dns for resolving domains I own. The other one is another dns that I'd like to use for my customers.

On the first one i set the forwarding to the second one and I have created a forward zone for a domain, pointing to the second bind server.

Server1:

acl internals {
  172.16.0.0/24;
  127.0.0.1;
  };
acl domain {
  192.168.1.0/24;
};
acl externals {
  any;
};
dnssec-enable yes;
dnssec-validation yes;
#dnssec-lookaside auto;

version "Not your job";
recursion yes;

allow-transfer { internals; domain;};
// restrict query access
allow-query { internals; externals; domain; };
// restrict recursion
allow-recursion { internals; domain; };

auth-nxdomain no;    # conform to RFC1035
forwarders {
  8.8.8.8;
  8.8.4.4;
};



view "externals" {
match-clients { "externals"; };
recursion no;

zone "my_customer_domain.com" {
type forward;
forwarders {
    172.16.0.150;
    };
 };
};

Server2 has the same kind of configuration but resolves only the my_*customer_*domain.com with an internal answer of 172.16.0.34 if the request is from "internals", the public IP if from "externals" and 192.168.1.4 if from "domain".

If I made a DIG from my pc (same subnet as "internals") to the "public" server I have the right answer (es: 172.16.0.34)

If I made a DIG from a domain pc (same subnet as "domain") to the "public" serverI get the "internal" ip

If I made a DIG from an external pc (dig NS my_*customer_*domain.com @8.8.8.8 ) I get the "internal" ip

All other kinds of queryes don't give any problem, even if I try to reach google.com from server2.

Note: server1 in "domain" and "internals" has "root zone". Server2 has "root zone" only for "internals"

Server1: ubuntu 20.04.05, Bind 9.16

Server2: ubuntu 20.04.05, Bind 9.16

So, users from Internet reach my server1 for the domain my_customer_domain.com (server1 is the public one, server2 is only internal). Server1 should then forward the query to server2 BUT server2 resolves with the INTERNAL ip of the zone, as defined in the records. I think that's because the query is origninating from server1 which is "internal" to server2 so the main question is....how to achieve the right behaviour?