Unexpected behaviour while blocking/whitelisting with similar regex rules

General Beta 5.0
1

Please follow the below template, it will help us to help you!

Please ensure that you are running the latest version of the beta code.
Run pihole -up to update to the latest, then verify that the problem still exists before reporting it.

Pi-hole version is v4.3.2-435-g5878502 (Latest: v4.4) AdminLTE version is v4.3.2-433-g0b4a5de5 (Latest: v4.3.3) FTL version is vDev-71e8498 (Latest: v4.3.1)

Problem with Beta 5.0:
I add rule ^xn--.*\..*$ to regex blacklist
and ^xn--.*\.de$ to the regex whitelist, as shown here:

temp
temp1489×225 32.9 KB

I expected that all punycode domains get blocked, except those ends with .de.

But now all punycode domains stays blocked.

Debug Token:
4n7y0m4yc6

2

The regex entries for punycode both appear to be black and not white:


*** [ DIAGNOSING ]: Domainlist (0/1 = exact/regex whitelist, 2/3 = exact/regex blacklist)
   id    type  domain                                                                                                enabled  date_added           date_modified        comment                                           
   ----  ----  ----------------------------------------------------------------------------------------------------  -------  -------------------  -------------------  --------------------------------------------------                                     
   134   3     ^xn--.*\..*$                                                                                          0        2020-02-25 23:08:29  2020-02-26 20:43:04                                                    
   135   2     ^xn--.*\.de$                                                                                          0        2020-02-25 23:08:54  2020-02-26 20:43:05

How did you add the regex entries? The web interface does seem to contradict the debug output.

4

I added them via the web interface.

5 
2/3 = exact/regex blacklist
6

I was curious and tested these two entries as described and its working exactly as expected.

7

Can you provide a debug token so we can compare the list type output?

8

It's up. cwrxuc9dyv

9

Thanks, looks like the type identifiers are incorrect in our display.

   450   3     ^xn--.*\..*$                                                                                          1        2020-02-26 21:15:59  2020-02-26 21:15:59                                                    
   451   2     ^xn--.*\.de$                                                                                          1        2020-02-26 21:16:35  2020-02-26 21:16:35
10
12

How did you verified that it works as expected?
I've tested it with a nslookup command on a win10 system using and tried to resolve müller.de, which is coverted to xn--mller-kva.de.

13

kva
kva310×600 4.01 KB

14

Okay, I have it now.

From the server’s CLI it got resolved correcty and after double-checking I saw that windows nslookup command had added the router's domain suffix (.fritz.box) to the domain.

Thanks to all.

1 Like
15

Thanks, it did bring up the debug output issue, thank you for that.

1 Like
16

One hint:
Some browsers like to try to add a www. before the FQDN. To make sure that this will be filtered too you'd better write

(\.|^)xn--.*\..*$
1 Like
17

4 posts were split to a new topic: Regex Chatter

18

Whoops. Put on the Todo. Thanks for notifying!

19

Incorrect debugger text fixed by

1 Like