filter-a and dns64 in a ipv6-only network

[Bjørn Mork]

Ondřej Surý <ondrej at isc.org> writes:

> Nobody is preventing from doing the work yourself, or paying somebody for doing
> the work for you. That's where the open-source model shines.

Or simply trigger the curiousity of some innocent victim who will then
do the work for free :-)

I don't necessarily believe this is a good idea, for all the reasons
presented earlier in this thread...

But I did't understan why Thomas could't just chain two BIND instances
together to achieve his goal.  So I had to try.  And found that it's
even possible to do it with views in a single instance, if that's
important.

This sort of "works" for me (although very broken by design, as already
noted):

options {
        directory "/tmp/c1";
        dnssec-validation auto;
        auth-nxdomain no;
        listen-on-v6 port 60053 { ::1; };
        listen-on port 60054 { 127.0.0.1; };
        server-id hostname;     // +nsid
        no-case-compress { any; };


};

view dns64 {
      match-destinations { 127.0.0.1; };
      recursion yes;
      dns64 64:ff9b::/96 {
        clients { any; };
        recursive-only yes;
        mapped { !10/8; any; };
    };
};

view clients {
  match-clients { any; };
  recursion yes;
  forward only;
  forwarders { 127.0.0.1 port 60054; };

    plugin query "filter-a.so" {
                  filter-a-on-v6 break-dnssec;
                  filter-a-on-v4 break-dnssec;
                  filter-a { ::/0 ; };
    };

};


Gives me DNS64 synthesis with A records filtered (i.e. double broken):

bjorn at miraculix:~$ dig a oracle.com @::1 -p 60053

; <<>> DiG 9.18.11-2-Debian <<>> a oracle.com @::1 -p 60053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37408
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 52dca01049a916320100000063da7fc70971947511271b6a (good)
;; QUESTION SECTION:
;oracle.com.                    IN      A

;; Query time: 220 msec
;; SERVER: ::1#60053(::1) (UDP)
;; WHEN: Wed Feb 01 16:05:43 CET 2023
;; MSG SIZE  rcvd: 67

bjorn at miraculix:~$ dig aaaa oracle.com @::1 -p 60053

; <<>> DiG 9.18.11-2-Debian <<>> aaaa oracle.com @::1 -p 60053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57965
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: ca0aab9924690d5c0100000063da7fce9c376cafcbc3f08e (good)
;; QUESTION SECTION:
;oracle.com.                    IN      AAAA

;; ANSWER SECTION:
oracle.com.             292     IN      AAAA    64:ff9b::8a01:21a2

;; Query time: 0 msec
;; SERVER: ::1#60053(::1) (UDP)
;; WHEN: Wed Feb 01 16:05:50 CET 2023
;; MSG SIZE  rcvd: 95




Feel free to replace the IPv4 loopback with some IPv6 address.  That was
just a convenient additional address I happened to have on my test
system :-)

And the odd port number is of course just for my test as an ordinary user.


Bjørn