Maintained by: NLnet Labs

[Unbound-users] AAAA filter patch proposal

W.C.A. Wijngaards
Thu Nov 13 10:10:51 CET 2014

Hash: SHA256

Hi Stephane,

On 13/11/14 04:08, Stephane Lapie wrote:
> Hello,
> There was a post several days ago about AAAA filter, and questions
> about an implementation as a Python module by Christophe.
>  I work at the same company as him (a Japanese ISP, which are all 
> subjected to NTT's flaky practices with use of IPv6), and have
> been working with him on this issue.

The patch looks to have nice clean code.

If you are looking for feedback on the code, this is what I can find:
iterator.h, comment for fetch_a_for_aaaa is misleading: say that a
subquery has been made for fetching A records.  It now seems as if the
flag is set in the subquery, but it is set in the superquery (to avoid
asking twice).

iterator.c, asn_processAAAAResponse: this routine can be shortened, I
think.  After changing the super_iq->state and log_query_info lines,
it can simply return.  However, the current code does not fail either
; it might be more 'optimal' and save the statemachine some work.

Thank you for publishing the patch.  Are you all right if I put this
patch in the source contrib/ directory to make it more easily
available to the users?

We don't provide support for the contrib material, but it may be
useful for users in weird circumstances.

Best regards,

> To sum up the scenario we are trying to fix : - customers in Japan
> have a physical carrier (NTT in most cases) on top of which they
> get their own internet provider, to which they connect via PPPoE.
> In our case, we currently provide only IPv4 service at this point 
> in time. - some customers also get an on-demand video service via
> his carrier, NTT, which give them a default IPv6 route via IPoE, or
> they raise a second PPPoE session (NTT usage terms allow for up to
> 2 sessions for this scenario). - the catch: said IPv6 default route
> does not go outside on the internet, and only enables access to
> NTT's closed network. Therefore, a customer in this configuration
> trying to access any IPv6 site is in for a world of pain as his
> browser times out and retries, hopefully fallbacking to IPv4. This
> prompted every Internet service provider in Japan to either provide
> native IPv6 or to filter AAAA records for "non-v6 only sites",
> which in this instance pretty much means everyone uses BIND.
> To answer Bill Manning's earlier statement, "we can not change 
> providers", first reason being because we ARE a provider, but also 
> because even if we wanted to change carriers, everyone in Japan is 
> entirely dependant on the majority physical carrier, i.e NTT. Since
> it happens at a lower layer than the ones we have control over (we
> work at PPPoE encapsulated level, they work at Ethernet level), we
> have no control whatsoever over said carrier-provided route, short
> of ourselves providing IPv6 service over or PPPoE and an overriding
> route, or via IPoE (and then tell NTT to buzz off and provide our
> route, if we had one). This is obviously scheduled as the proper
> solution, but requires overhauling all of the network
> infrastructure, which can not be done instantly.
> Also, thanks a lot to Daisuke Higashi for his statement, using 
> "private-address/private-domain" is initially what we planned on
> doing, except this gets scary when we think about "what if NTT
> springs yet another domain on top of that, that we need to allow
> access to?" or "what if another customer tries to access yet
> another IPv6-only site in the future?", and the "whack-a-mole"
> administration nightmare it might become.
> In the meantime, we still need to get rid of BIND, which can't
> handle the resource exhaustion DDoS attacks 
> (
we are seeing since february of this year. This is where we wanted to go
> with unbound, except since it does not have AAAA-filter
> functionality, we could not use it in production for most of our
> customers.
> This is where Christophe attempted to intercept queries with Python
> and we found out : - Python API does not enable to spawn sub
> queries (for each AAAA query, the relevant A record has to exist in
> cache, for AAAA filter logic to work) - Python API does not enable
> to lookup RRset cache for a given record (in this case, for an A
> record matching the queried name) - Python API does not allow for
> easy scrubbing of packets (it IS possible, but very painful)
> I therefore came to the conclusion that the Python API was not 
> appropriate to do these things, and that the most appropriate place
> to implement a filtering/scrubbing logic was the iterator module
> itself.
> I coded the following patch (also attached) : 
> It
> has been on tests and running in pre-production for roughly a
> month now (while undergoing some tuning as I got around to
> understanding how the state machine works).
> The patch provides : - a "aaaa-filter" config option which is off
> by default, so as to not be intrusive (I am fully aware this
> functionality is enough of an abomination as is). It can also be
> used in conjunction to private-address/private-domain without any
> issues. - the relevant manual entry - modifications to
> iterator/iter_scrub.c in scrub_sanitize() to remove AAAA records
> for queries that either are not AAAA type, OR that did return an A
> record, IF cfg->aaaa_filter is enabled. - modifications to
> iterator/iter_utils.c to provide AAAA filter "on/off" info to the
> iterator environment. - modifications to iterator/iterator.c : -- a
> new ASN_FETCH_A_FOR_AAAA_STATE from which we branch into from 
> QUERYTARGETS_STATE if this is a AAAA query (modifies
> iter_handle(), iter_state_to_string(),
> iter_state_is_responsestate(), -- asn_processQueryAAAA() function
> that throws a subquery and flags the parent query as "already
> fetching an A subquery" so as to not loop -- modifications to
> iter_inform_super() to handle the new state for AAAA parent queries
> having a A subquery. -- asn_processAAAAResponse() function that
> basically takes after what error_supers() and
> processTargetResponse() do, except it does not alter target queries
> counters. - modifications to iterator/iterator.h : declaration of
> new flags for iter_env (configuration option), iter_qstate (status
> flag), and the new iter_state
> At this point, the patch is pretty much stable and performing as 
> expected, but I am looking for pointers as to stuff I could improve
> on that patch, especially style-wise, to ensure it is applicable as
> long as possible. In its current state, I can apply it up to
> 1.4.22.
> I also know from previous postings that unbound development
> staff's opinion is that this functionality as a whole would harm
> IPv6 adoption, and therefore can probably not be officially
> endorsed, but I still intend to provide it freely (my company has
> given approval) to people suffering from the same scenario. (that
> is, mainly Japanese users at this point...)
> Thanks for your time,
> _______________________________________________ Unbound-users
> mailing list Unbound-users at 

Version: GnuPG v1