Blocked A but Resolved AAAA

[shizunge]

I have seen blocky blocked A type (expected) but resolved AAAA type (unexpected) for the same domain.

Try to reproduce it and then I will file an issue.

[shizunge]

I am able to reproduce the problem with the following setup:

Run two blocky instances, the base one use dns.google as upstream, while the front one use the base one as upstream.

Then send dns query to the front one:

dig @172.20.0.2 -p 5353 g.live.com AAAA ;

Saw the following in the log files:
base log:

2023-02-01 05:57:55     172.20.0.2      172.20.0.2      38      BLOCKED CNAME (default-lists)   AAAA (g.live.com.)      AAAA (::)       NOERROR

front log:

2023-02-01 05:57:55     172.20.0.1      172.20.0.1      86      RESOLVED (tcp+udp:172.20.0.3:5353)      AAAA (g.live.com.)      AAAA (::)       NOERROR

I saw the query in the base log, which indicated that the front did forward the query to its upstream, even though the domain was eventually blocked.

I can actually reproduce the problem with A type with this setup as well.

---

docker-compose.yml

version: '3.8'

services:
  blocky_app_base:
    image: ghcr.io/0xerr0r/blocky
    user: 1000:1000
    cap_add:
      - NET_BIND_SERVICE
    healthcheck:
      disable: true
    ports:
      - 5454:5353
    networks:
      blocky_net:
        ipv4_address: 172.20.0.3
    volumes:
      - ./blocky-base-config.yml:/app/config.yml
      - ./logs-base:/app/logs

  blocky_app_front:
    image: ghcr.io/0xerr0r/blocky
    user: 1000:1000
    cap_add:
      - NET_BIND_SERVICE
    healthcheck:
      disable: true
    ports:
      - 5353:5353
    networks:
      blocky_net:
        ipv4_address: 172.20.0.2
    volumes:
      - ./blocky-front-config.yml:/app/config.yml
      - ./logs-front:/app/logs


networks:
  blocky_net:
    ipam:
      driver: default
      config:
        - subnet: "172.20.0.0/24"

blocky-base-config.yml

upstream:
  default:
    - tcp+udp:8.8.8.8:53
upstreamTimeout: 5s
startVerifyUpstream: false
connectIPVersion: dual
blocking:
  blockType: zeroIp
  blockTTL: 1s
  startStrategy: blocking
  clientGroupsBlock:
    default:
      - default-lists
  blackLists:
    default-lists:
      - https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt
  whiteLists:
    default-lists:
      - |
        example.com
queryLog:
  type: csv
  target: /app/logs
port: 5353
bootstrapDns: tcp+udp:127.0.0.11
logLevel: info
logFormat: text
logTimestamp: true
logPrivacy: false

blocky-front-config.yml

upstream:
  default:
    - tcp+udp:172.20.0.3:5353
upstreamTimeout: 5s
startVerifyUpstream: false
connectIPVersion: dual
blocking:
  blockType: zeroIp
  blockTTL: 1s
  startStrategy: blocking
  clientGroupsBlock:
    default:
      - default-lists
  blackLists:
    default-lists:
      - https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt
  whiteLists:
    default-lists:
      - |
        example.com
queryLog:
  type: csv
  target: /app/logs
port: 5353
bootstrapDns: tcp+udp:127.0.0.11
logLevel: info
logFormat: text
logTimestamp: true
logPrivacy: false

[kwitsch]

Ok that seems kinda strange.
If the request isn't blocked by front and base blocks with zeroIp the resolved entry is correct.
But since both use the same blocklists the request shouldn't be send to base...

Could you test it with a manual block entry in both configs to ensure it isn't a list loading error?

[shizunge]

We can explain it due to g.live.com is not directly blocked, but blocked via CNAME.

How do I know whether there is a list loading error?

[kwitsch]

The front instance doesn't block even if you add g.live.com like

...
blackLists:
    default-lists:
      - https://raw.githubusercontent.com/crazy-max/WindowsSpyBlocker/master/data/hosts/spy.txt
      - |
        g.live.com
...

?

If you set logLevel to debug there should be more information in your logfile regarding internal problems.

[shizunge]

Yes it got blocked.

Yet I saw that if I set "base" to" bypass" mode (i.e. no blocking), the front still resolve the domain. I have not checked whether it is loading problem.