[FR] Option to provide only A/AAAA records

[t-leslie]

As part of moving our network to IPv6 only, we're using DNS64, which works as expected with unbound when querying AAAA records for sites that only have IPv4 setups.

One challenge in taking the next step is that there does not appear to be a way to have unbound provide only AAAA records. This results in IPv6 queries resulting in A records, and continued pressure/traffic on my IPv4 system, rather than transitioning all traffic other than needed IPv4 traffic to IPv6. I'm trying to have unbound ONLY provide AAAA records.

Perhaps I'm missing a respip setting or some other query option? Respip can filter all A queries (or all AAAA queries), but it doesn't get my dig commands to see the great responses waiting for them in AAAA land. Respip also seems heavy handed, filtering after a response comes back, rather than stopping it before going out.

I can see a situation where individuals may want to restrict responses to only be A records, though that is not my circumstance.

Secondary request: Since 'dns64 subnetcache respip validator iterator' works, can we also assume that 'dns64 respip validator iterator' works and remove the error code? All 'potential error' codes throw failure notices in OpenBSD's rc script, even if it would normally start.

#unbound -V
Version 1.13.2

Configure line: --enable-allsymbols --with-ssl=/usr --with-libevent=/usr --with-libexpat=/usr --without-pythonmodule --with-chroot-dir=/var/unbound --with-pidfile= --with-rootkey-file=/var/unbound/db/root.key --with-conf-file=/var/unbound/etc/unbound.conf --with-username=_unbound --disable-shared --disable-explicit-port-randomisation --without-pthreads
Linked libs: pluggable-libevent 1.4.15-stable (it uses kqueue), LibreSSL 3.4.1
Linked modules: dns64 respip validator iterator

cat unbound.conf

$OpenBSD: unbound.conf,v 1.21 2020/10/28 11:35:58 sthen Exp $

server:
verbosity: 1

interface: ::0

port: 53

do-ip4: no
do-ip6: yes

module-config: "dns64 validator iterator"
dns64-prefix: 64:FF9B::/96
access-control: ::1 allow
access-control: X:X:X:X::/64 allow

root-hints: "/var/unbound/etc/root.hints"

hide-identity: yes
hide-version: yes

harden-glue: yes

harden-dnssec-stripped: yes

use-caps-for-id: yes

cache-min-ttl: 3600
cache-max-ttl: 86400
prefetch: yes
num-threads: 4
msg-cache-slabs: 8
rrset-cache-slabs: 8
infra-cache-slabs: 8
key-cache-slabs: 8

so-rcvbuf: 1m

unwanted-reply-threshold: 10000

do-not-query-localhost: no

val-clean-additional: yes

forward-zone:
name: "."
forward-addr: 2620:fe::fe #Quad9 IPv6
forward-addr: 2620:fe::9 #Quad9 IPv6-2

[PMunch]

It would be possible to do this with a custom dynamic library module. Simply check the type of the query, and stop the query if it isn't AAAA. This of course does mean you have to build with --with-dynlibmodule and that you're able to write a small dynamic library.

[tiagogaspar8]

Hi @PMunch @t-leslie ,

I'm having a similar issue, where fallback isn't working as expected. So, situation is:

1. A client looks up "example.com" which has a ipv4 and ipv6 address.
2. Unbound replies with the respective IPv6 and IPv4
3. The client accesses via IPv6 since it is a IPv6 only network

Now imagine the following scenario, IPv6 server is down, what happens is:

1. A client looks up "example.com" which has a ipv4 and ipv6 address.
2. Unbound replies with the respective IPv6 and IPv4
3. The client accesses via IPv6 since it is a IPv6 only network, but it can't since it is down
4. The client gives up cause there is no other available address

This is extremely unpleasant and unnecessary since the IPv4 is reachable trough nat64, but since unbound only translates records for which there is no AAAA record, it fails.
Why is this? Why does unbound even serve IPv4 even though we know that there is a nat64 translator (which means there is no IPv4 available)? And why doesn't unbound translate all records, even the ones with AAAA records?

If this should be in a separate issue let me know, but this is very bad and can break happy eyeballs.

Thanks!

[maurice-w]

Hi @t-leslie, I found this issue while working on a AAAA-only feature for OPNsense. After some initial testing, this is what seems to work for me:

module-config: "respip dns64 validator iterator"
response-ip: 0.0.0.0/0 redirect

Yes, unbound still resolves A records and only filters them in the last step, but this seems acceptable to me.

@tiagogaspar8, your issue is different and there actually is an option to "synthesize all AAAA records despite the presence of actual AAAA records": dns64-synthall: yes

[chrcoluk]

I +1 this request.

My reasoming is Chrome (and its forks) now no longer respect Windows prefix policy, my IPv6 goes over slow connectivity so I preference IPv4, the browser ignores it, so I get slow youtube etc. So I am faced with either removing AAAA from DNS results or disabling IPv6 entirely. The former been less destructive.

@maurice-w are you able to please provide your solution but for filtering IPv6 instead? Just WAN IPv6 not LAN IPv6. All IPv6 is ok if it cant do WAN only.

Ended up using this for now, on pfsense also had to patch unbound.inc to add respip support.

response-ip: 0::/128 redirect

Little update it will show both A and AAAA on first result, and only filter on 2nd result onwards. My analysis seems to indicate this will only filter 'cached' responses.

[thomasschaeferm]

@maurice-w
Thank you for the talk yesterday! I forgot to ask you how you removed the a-records (behind the cross mark in opensense). But now I found it - and it works!
module-config: "respip dns64 validator iterator"
response-ip: 0.0.0.0/0 redirect

[maurice-w]

@thomasschaeferm Yes, that's how I ended up implementing it in OPNsense without having to patch Unbound. Which is what @pavel-odintsov recently did in #819! Their approach looks much cleaner, so once it's made its way into an Unbound version used by OPNsense, I might switch to this solution.

[Daniel-at-git]

@thomasschaeferm Thanks for this hint. Filtering AAA with unbound can be configured with

module-config: "respip iterator"  
response-ip: ::/0 redirect

Can we close this FR?