My setup:
------------------standard aspects of my setup----------------------------------
-- A home lan with headless-not wireless pizero with pihole in
192.168.1.201 connected via cable to the home adsl gateway/router
-- On the gateway i have set 192.168.1.201 as a dns primary server.
-- I do the tests mentioned below from an ubuntu+xfce 18.04 host
which get is address from dchp from the gateway.
-- In firefox i took extra care to check that DoH is not enabled. And
frequently i cleared it's dns cache.
-- A previous setup with pihole on a host of my homelan
worked eventually and that's a reason i thought the problem was to
the host network setup.
---------------changes i try in my host to solve the issue --------------
But due to experimentation and the rich!! network related services (systemd.resolved , dhcpcd.service, NetworkManager.service , resolvconf.service , and related conf files /etc/network/interfaces , /etc/nsswitch.conf, (and all the related conf file of the mentioned services) . I have made many tries disabling them or changing some of their config trying to find if my host has the problem.
Like altering host line in nsswitch , or instructing dhcpd not to alter
resolvconf, or reconfiguring resolvconf not to change resolv.conf and
some other tweeks. ) Also i tried many times from network manager to change
my wireless interface's settting from manual to auto and then back to manual..
Frankly and i have to say that...i feel that i run a mobile server!! when its just a small home pc! Why do i need all those stuff guys? Did i mentioned that i also give netplan an try? Crazy at least. 
Expected Behaviour:
From the webinterface of pihole i blacklist some domains. And i expect firefox
(my casual browser) to block them.
Actual Behaviour:
The pihole blocked domains are blocked from epiphany-browser , and from
dns test utilities like dig , nslookup but not from ping and firefox.
And for what is worth in the queries logs i see: mozilla.cloudfare-dns.com.
(i've set cloudface as passthrough dns in the pihole, but still suspect 
)
Epiphany will also display the pihole's block webpage which is very nicely put.
So for example having blacklisted 'stackoverflow' i will get :
$ dig stackoverflow.com
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> stackoverflow.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57714
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;stackoverflow.com. IN A
;; ANSWER SECTION:
stackoverflow.com. 2 IN A 0.0.0.0
;; Query time: 6 msec
;; SERVER: 192.168.1.201#53(192.168.1.201)
;; WHEN: Fri Jan 15 08:34:35 EET 2021
;; MSG SIZE rcvd: 51
Debug Token: 6777py79a8
Note that ping isn't adequate to analyse DNS issues as it uses additional sources to resolve hostnames, not just DNS.
Your router/DHCP server is distributing itself as DNS server alongside Pi-hole:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
* Received 548 bytes from eth0:192.168.1.1
Offered IP address: 192.168.1.5
DHCP options:
Message type: DHCPOFFER (2)
router: 192.168.1.1
dns-server: 192.168.1.201
dns-server: 192.168.1.1
lease-time: 1814400 ( 21d )
--- end of options ---
This means that DNS requests of your DHCP clients will bypass Pi-hole via your router as they see fit.
EDIT: E.g. they may send one request towards Pi-hole and the next two towards your router, or they may develop a more or less pronounced preference for your router.
Pi-hole has to be the only DNS server on your network.
Thank you . Indeed the issue is from that host only and from a windows 10 host. In another host with debian 10 all browsers , vivaldi , chrome , falkon, epiphany , even latest firefox downloaded work .
So i'll try the parallel dhcp server you said and then try my windows host.
So , i guess you mean that the issue is in the pizero and should be fixed by ssh in pizero.? Because thats where i executed $ pihole -d . And if that is so , then why other debian host works ok?]
Now that i think it over.... Its my first with the headless pizero and ssh in it i get:
$ less /etc/resolv.conf
#Generated by resolvconf
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fd51:42f8:caae:d92e::1
So i wonder , does it matter what pizero 's dns settings are?
For example i found a webpage proposing to turn off dhcp on the router and let pihole handle it.
In another ubuntu 18.04 laptop where pihole works , (blocked lists are not accessible from firefox) i get:
[192.168.1.2]$ nmcli -t
DNS configuration:
servers: 192.168.1.201 192.168.1.1
interface: wlp3s0
servers: fe80::1
interface: wlp3s0
[192.168.1.2]$ less /etc/nsswitch.conf
...
hosts: files mdns4_minimal [NOTFOUND=return] dns
...
and in the host with the issue:
[192.168.1.4]$ nmcli -t configuration:
servers: 192.168.1.201 192.168.1.1
interface: wlxc025e91a0bef
servers: fe80::1
interface: wlxc025e91a0bef
[192.168.1.4]$ less /etc/nsswitch.conf
...
hosts: files mdns4_minimal [NOTFOUND=return] dns
...
The same output i get on the ubuntu host with the issue.So maybe the problem is in the host. And of course i'll check the windows 10 host later..
Trying to understand why in my host who wont use pihole blocklist i saw that:
[192.168.1.4]$ ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Ιαν 15 01:58 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
So trying to better understand the relation between systemd-resolved.service and resolvconf.service i come upon A name resolution issue with systemd-resolved we found in the wild.
So i am reading in and i wonder how deep the hole goes...
Ok. i purged resolvconf , i disabled systemd.resolved , and voila
dhcpcd took command of /etc/resolv.conf so i decided to take a manual ip from network manager.
Now /etc/resolv.conf seems ... calm. with just 192.168.1.201 (my pizero).
But still firefox does it funny things!!
Ok. Thinking about it, if i uninstall firefox i have no problem!
The troublesome condition is that if an application can do its own dns resolution you cant be sure if your central dns filter intercept every dns request.
So epiphany and falcon in my host with the issue works ok.
Please post a new debug token.