ECS-IP not visible in the "rpz.log"

Summary

If an RPZ-enabled BIND is behind a proxy/loadbalancer (for example dnsdist), which injects the ECS-IP, there's actually no way to have/see the client ip address (ECS-IP) in the "rpz.log". Instead, one can correctly see only the ip address from the proxy/dnsdist itself and not the address from the effective source.

BIND version used

Tested with BIND-9.16.21

Steps to reproduce

Place a proxy/dnsdist in front of BIND and inject the ECS-IP.

Domain Name System (response)
    Transaction ID: 0x5d00
    Flags: 0x8183 Standard query response, No such name
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 1... .... = Recursion available: Server can do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0011 = Reply code: No such name (3)
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        example.ch: type A, class IN
            Name: example.ch
            [Name Length: 8]
            [Label Count: 2]
            Type: A (Host Address) (1)
            Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (41)
            UDP payload size: 1232
            Higher bits in extended RCODE: 0x00
            EDNS0 version: 0
            Z: 0x0000
                0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
                .000 0000 0000 0000 = Reserved: 0x0000
            Data length: 40
            Option: COOKIE
                Option Code: COOKIE (10)
                Option Length: 24
                Option Data: faf2434380c56c3d01000000617a1b9c7be4e739ff1b30de
                Client Cookie: faf2434380c56c3d
                Server Cookie: 01000000617a1b9c7be4e739ff1b30de
            Option: CSUBNET - Client subnet
                Option Code: CSUBNET - Client subnet (8)
                Option Length: 8
                Option Data: 00012000c0a8ec02
                Family: IPv4 (1)
                Source Netmask: 32
                Scope Netmask: 0
                Client Subnet: 172.16.16.33                     <------------------
    [Request In: 13]
    [Time: 0.000221000 seconds]

Then query a domain via proxy, which triggers RPZ

What is the current bug behavior?

Verify the "rpz.log", which only shows the proxy-ip

27-Oct-2021 15:41:27.940 rpz: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): rpz QNAME NXDOMAIN rewrite example.ch/A/IN via example.ch.blacklist-rpz.test.local

What is the expected correct behavior?

A way to see the ECS-IP, the effective client ip address, like this is already implemented, when enabling the builtin "rndc querylog on":

27-Oct-2021 15:41:27.940 queries: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): query: example.ch IN A +E(0)K (127.0.0.1) [ECS 172.16.16.33/32/0]

Relevant configuration files

(Paste any relevant configuration files - please use code blocks (```) to format console output. If submitting the contents of your configuration file in a non-confidential Issue, it is advisable to obscure key secrets: this can be done automatically by using named-checkconf -px.)

GitLab