unbound
unbound copied to clipboard
NLnetLabs
Implement block_aaaa similar to block_a
Reason behind this is that certain ancient apps get confused with IPv6 and stuff, so offer possibility to make them work too.
I actually made a good use of this for sites and domains that are too restrictive and would ban outright public IPv6 tunnel brokers for example (as I "sit" on one of them) together with netfilter filtering aswell. Would be a nice feature to have...
Gentle ping :)
Could we look to merge this? This is quite similar to the block_a zone-type implementation and would help our network a fair bit too!
The item belongs to @Philip-NLnetLabs . And he tells me that he does not want it because it breaks DNSSEC. DNSSEC would not work for downstream validators. The code looks nice otherwise.
I've not read how this breaks DNSSEC but the fix for this should be identical for both block_a (already merged) and blocked_aaaa. There are systems that don't use DNSSEC today (and might not anytime soon, eg: private-only networks) that could benefit from this so can we move the DNSSEC support into another issue?
Hello Are we looking forward to merge this change? This looks fine to me also. This will help our internal network in reducing a good amount of network calls :)
Ended up here because "private-address: ::/0" seems to be breaking some clients as it seems to return SERVFAIL adding that line...and i want no IPv6 addresses because my ISP doesn't do IPv6 and so clients take ages timing out on IPv6 before they use IPv4
We REALLY need some way to block IPv6 addresses in DNS when you know the ISP doesn't support DNS so that clients don't lag trying to connect to something it will never successfully reach.
@mmiller7 , if you need something global (and not per domain functionality that this issue is about) you can use:
server:
...
module-config: "respip validator iterator" # add your other modules as well but respip is needed
response-ip: ::/0 redirect
@mmiller7 , if you need something global (and not per domain functionality that this issue is about) you can use:
server: ... module-config: "respip validator iterator" # add your other modules as well but respip is needed response-ip: ::/0 redirect
Oh cool, I haven't found that anywhere else...did seem to do the trick!
@Philip-NLnetLabs - sorry for the repeated pings but what do you think about this proposal? This is identical to an existing feature block_a so hopefully should not increase maintenance cost much.
If there's a concern about this working with DNSSEC, I think this is already broken with block_a and we can separately track a fix for both of them, right? This feature does provide value-add so it'd be great if we could merge this. Adding on, DNSSEC is not widely used especially in internal cloud environments so there's probably a fairly large user-base that wouldn't be concerned by the lack of compatibility b/w this feature and DNSSEC.
Thanks for the response, Philip! Is there any documentation around the breakage for DNSSEC? Apart from the comment above by Wouter, I don't think this has been documented anywhere.
If the fix is straight-forward, maybe we can fix it as part of this PR. If this is a complex fix, I'd suggest again that we track it separately since noone has raised concerns with block_a and fixing for block_aaaa won't increase that effort. Note that I am not the original author of this PR or the original one for block_a and have no experience with DNSSEC 😓
What do you think?
For DNSSEC, there are two things that need to be done, preferably with additional tests to show that it works:
- if an address is deleted, make sure that the reply does not have the AD bit set.
- If the request has to DO bit set, then do not change anything, just return the unmodified reply.