BLOCKINGMODE NULL vs NODATA

Hi All,

First post!

I setup my pihole last night and configured my router to use it's ip as the DNS server.

Everything is working wonderfully, very easy to use and advanced enough that it covers all my needs (I think).

I know what the differences between NULL vs NODATA are and am wondering what would be ideal in my circumstance.

I run quite a few internet facing servers from my desktop. When NULL is being used for the BLOCKINGMODE then the ip returned is 0.0.0.0 for blocked domains. But since I run a web server the requests are being handled by nginx and returning 404s, which I guess might be fine.

In my case I think it makes more sense to use NODATA, does that make sense?

https://docs.pi-hole.net/ftldns/blockingmode/
doesn't mention that NULL is disadvantaged with my setup, but perhaps it is.

Thanks!

It's probably best to stick with default blocking mode.
See also this warning from our docs on Blocking mode:

The block page can only be displayed for unencrypted http connections. Since the majority of web pages today are accessed over encrypted https connections, no block page will be displayed. This option may be removed in the future.

Hi Bucking_Horn, thanks for the reply.
That warning is only in regards to IP-NODATA-AAAA and IP blocking modes. I'm specifically talking about the default NULL in comparison to NODATA.

My worry is that when using the default blocking mode NULL, and browsing from a workstation that has a local webserver present (in my case nginx), that blocked requests are actually hitting my webserver.

Using NODATA instead of the default NULL fixes this issue, so I was just checking if this is the expected behaviour.

Ex, when configured as NULL.

mrplow@dan-server:~$ curl ads.facebook.com
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>

mrplow@dan-server:~$ tail -n 1 /var/log/nginx/access.log
127.0.0.1 - - [27/Jan/2022:08:30:37 -0800] "GET / HTTP/1.1" 404 162 "-" "curl/7.74.0"

Yes, the (deprecated) blocking page may be served by aforementioned modes. With NULL blocking, there is no blocking page involved.

Webservers are not answering DNS requests, and DNS servers are not considered with HTTP. A default Pi-hole wouldn't be involved with any HTTP status codes (like your 404).

In the case of NULL blocking, when Pi-hole would be blocking a domain that you happen to run a webserver for, your client would not be able to communicate with it at all to begin with, and as no request ever reaches the webserver, it would be impossible for that client to receive an HTTP status code from a webserver as a response.
A browser that tries to access resources addressed via such a domain would instead show an error similar to "This site can’t be reached: ads.facebook.com’s server IP address could not be found. (ERR_NAME_NOT_RESOLVED)".

I think I'm explaining this wrong.

When NULL is set then pihole is returning 0.0.0.0 as the ip address for a blocked domain. Per the docs, "Following RFC 3513, Internet Protocol Version 6 (IPv6) Addressing Architecture, section 2.5.2, the address 0:0:0:0:0:0:0:0 (or :: for short) is the unspecified address. It must never be assigned to any node and indicates the absence of an address. Following RFC1122, section 3.2, the address 0.0.0.0 can be understood as the IPv4 equivalent of :: ."
This is matching the behaviour I'm seeing:

mrplow@dan-server:~$ dig ads.facebook.com

; <<>> DiG 9.16.15-Ubuntu <<>> ads.facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18322
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ads.facebook.com.              IN      A

;; ANSWER SECTION:
ads.facebook.com.       2       IN      A       0.0.0.0

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Jan 27 10:46:05 PST 2022
;; MSG SIZE  rcvd: 61

When I browse to a site that's being blocked by pihole it is directing the request to 0.0.0.0, which would normally be fine. But, if you have a web server running then it requests 0.0.0.0 aka localhost aka 127.0.0.1 then my web server is trying to serve the request and hence why I'm seeing 404s in my nginx log that directly corresponds to my trying to browse a site blocked by pihole.

As this would only apply to co-located HTTP requests from the same machine, this should probably be addressed by adopting your web server configuration.

Other clients would see the mentioned ERR_NAME_NOT_RESOLVED.

Pihole is running on a pi and my server is a separate box.

I would expect this would be a potential concern for anyone running a webserver that can be accessed through 0.0.0.0.

That being said, as I was typing my last reply I thought it would probably best to update ngix to listed on my local 192 ip rather than all interfaces.

Thanks for steering me in the right direction. I'll update my nginx config after work.

1 Like

Sometimes, language is more malleable than we intend it to be. :wink:
With my current understanding, your initial request seems somewhat obvious. But just as obvious, I failed to see your concern for same-site requests when I first read it.

1 Like

Figured it out after updating my nginx to listen only to my private ip instead of 0.0.0.0 as it does by default

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.