Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement block_aaaa similar to block_a #884

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

strlcat
Copy link

@strlcat strlcat commented Apr 29, 2023

Reason behind this is that certain ancient apps
get confused with IPv6 and stuff, so offer possibility to make them work too.

Reason behind this is that certain ancient apps
get confused with IPv6 and stuff, so offer possibility
to make them work too.
@winooxx
Copy link

winooxx commented Jul 29, 2023

nice implemetation

@jailbird777
Copy link

Any change to get this merged?

@strlcat
Copy link
Author

strlcat commented Sep 12, 2023

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...

@gauthamw-stripe
Copy link

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!

@rozhuk-im
Copy link

@wcawijngaards Please!

@wcawijngaards
Copy link
Member

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.

@rozhuk-im
Copy link

But it do same as block_a, may be just add note to docs about this?

@gauthamw-stripe
Copy link

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?

@ashwin316
Copy link

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 :)

@mmiller7
Copy link

mmiller7 commented Nov 19, 2023

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.

@gthess
Copy link
Member

gthess commented Nov 20, 2023

@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
Copy link

@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!

@gauthamw-stripe
Copy link

gauthamw-stripe commented Apr 11, 2024

@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.

@Philip-NLnetLabs
Copy link
Member

Why not rework the patch to fix the DNSSEC issues first?

@gauthamw-stripe
Copy link

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?

@Philip-NLnetLabs
Copy link
Member

For DNSSEC, there are two things that need to be done, preferably with additional tests to show that it works:

  1. if an address is deleted, make sure that the reply does not have the AD bit set.
  2. If the request has to DO bit set, then do not change anything, just return the unmodified reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants