[Unbound-users] AAAA filter patch proposal

Thu Nov 13 09:10:51 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
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.
> 
> https://unbound.net/pipermail/unbound-users/2014-October/003579.html
>
>  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,
   Wouter

> 
> 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 
> (http://dnsamplificationattacks.blogspot.jp/2014/02/authoritative-name-server-attack.html)
>
> 
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) : 
> http://www.yomi.darkbsd.org/~darksoul/aaaa-filter-iterator.patch 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 unbound.net 
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUZHWbAAoJEJ9vHC1+BF+NUOsP/A5dda9jiiSWWi+/ZV7g3yBL
5dAKMjs8YVPgUoVaUiBelb22rNyyqsze13qN+qfw5CyC3UdvsAq44KzcAKxvYc1N
pFoT8FE5rhjXp6gsToYMToTyI36P6gC3hVSJdKQWNH3wNKZ8yU+vSpSIWPkHA9Ge
lH/yIH0HSqNjcRUzspjyBCQItSEdKCEFCw1IDu5mm4BEArc1cLZxXma4yRFD1c63
Ju35UmcjV+cXQchfbV6Vv0ePbpI2ibQhfJRrd1p6QdFE0jLjT+pLuLsH/KkIEarn
CTe0PSC/05rGCNSppXyXGsLSVdWMHopSBUKa+8owvn8rmi2VQah8kEwAh5a+tluS
PLLeJms4yyIBFaVOoHtmPAcGw0UU41IpXcNbMM/5Fsc6as74C/pF0FNf4xYALQ5x
iK0Uz6CahD+K5PMQ6O3An06b9nSu9aHxNTH7g2qIJv2nx6E03/FFGpumYYKuOaIp
fOdYD2u9njdf4et5HvshmzNziSlzKqKdvHyPGmjmKZWaz2JXMCI7X6qzx5UyDcrF
buE1TwXAuhnFOOt3sWWhVzS6lH/JPI8VMuFko9OZJl+pY4cO1ONST3bfWcDnpJo6
uqJOv2e74Gxm/XDevetlYFfEFSUHGHa/B/np5dDp+ExdwU8aRBKy8GgqDwqsC+I7
sRpE7qjMPZaFwcFUm8TK
=TUHX
-----END PGP SIGNATURE-----