filterdns needs help for IPv6
|Affected version:||2.1-IPv6||Affected Architecture:|
filterdns appears to solely use IPv4 IPs in aliases. Need to determine how to handle that, especially whether PF tables will take a mix of v4 and v6 IPs.
Add IPv6 support for hostnames. Does not currently work with masks smaller or larger then 32 IPv4 bits.
If the IPv4 mask is set to 32 bits the IPv6 mask is set to 128 so it matches 1:1
When a IPv4 mask is less then 32 bits we multiply it by 2 for the IPv6 mask. So a /24 IPv4 becomes a /48 IPv6.
redmine ticket #2506
#1 Updated by Chris Buechler 11 months ago
- Subject changed from Aliases/FilterDNS not Resolving IPv6 first to filterdns needs help for IPv6
- Description updated (diff)
- Target version set to 2.1
Aliases can have both IPv4 and IPv6 addresses. Ermal did add some IPv6 support bits, but I'm not sure if he added quad A support.
b83amd64# host pro6pp.appspot.com
pro6pp.appspot.com is an alias for appspot.l.google.com.
appspot.l.google.com has address 18.104.22.168
appspot.l.google.com has IPv6 address 2a00:1450:8005::8d
Logfile seems rather funky, the IPv4 octets are reversed, the IPv6 octets are even shuffled.
Could be a misconfigured alignment.
Also, the host masks are shuffled, the IPv4 mask is 32, which is a single host, the IPv6 mask is also 32 which is a huge swath of space. Which might be somewhat accurate for Google but not something that should be relied on.
My suggestions would be to add a host or network field in the filterdns config file so that it knows what size to use. Maybe we should use /32 and /128 hardcoded for now. Alternatively make it a /64 for IPv6 so it's limited to a single "prefix".
My rather inaccurate alternative would be to double the IPv4 bits. e.g. you have a /32 it would translate to /64 which is a normal prefix and about right, but not very strict. A /16 would mean a /32 which could still be wildly inaccurate but a better guesttimate to the network size.
I have a /24, and that translates exactly to the /48 I have here.
The big problem here is that we need to tell the hostname aliases which mask applies to which address family.
One such workaround I thought of is adding a hostname twice in the aliases, if the mask is > 32 bits, apply that against the Quad A records and add a /32 IPv4 record for safety belts.
I can confirm that it is not adding the IPv6 addresses it's finding to the pf table.
A quick look for the ext_pro6pp table under diag tables shows this.
pfctl -t ext_pro6pp -T show
I tried patching filterdns for a bit and had some wildly differing results. I did manage to get it to add IPv6 records to the tables, as a /32 ofcourse.
Jul 26 15:26:15 filterdns: Not cleaning table management host leaf.dnsalias.org.
Jul 26 15:26:15 filterdns: Not cleaning table ext_pro6pp host pro6pp.appspot.com.
Jul 26 15:26:15 filterdns: Found 2 entries for pro6pp.appspot.com
Jul 26 15:26:15 filterdns: adding entry 0.0.173.194 to table ext_pro6pp on host pro6pp.appspot.com
Jul 26 15:26:15 filterdns: found entry 0.0.173.194 for ext_pro6pp
Jul 26 15:26:15 filterdns: adding entry ::2a00:1450:8005:0:0 to table ext_pro6pp on host pro6pp.appspot.com
Jul 26 15:26:15 filterdns: found entry ::2a00:1450:8005:0:0 for ext_pro6pp
Jul 26 15:26:15 filterdns: Found 1 entries for leaf.dnsalias.org
Jul 26 15:26:15 filterdns: adding entry 0.0.192.168 to table management on host leaf.dnsalias.org
Jul 26 15:26:15 filterdns: found entry 0.0.192.168 for management
Jul 26 15:26:15 filterdns: Found hostname leaf.dnsalias.org with netmask 32.
Jul 26 15:26:15 filterdns: Found hostname pro6pp.appspot.com with netmask 32.
- Status changed from New to Feedback
Ok, with added patches it now adds the IPv6 addresses with a subnet mask of 128 for hostnames. Should show up in a build soon.
Still need to verify that it sets the calculated IPv6 address mask for IPv4 lengths < 32 bits.