<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello Wouter,<br>
<br>
Many thanks for the quick reply and review.<br>
<br>
Right, that comment in iterator.h is a remnant of something I
initially planned on doing, and changed ideas along the road.<br>
I just fixed it.<br>
<br>
As for processAAAAResponse, I wrote it this way to get a verbose
trace of what is going on should it fail. (based mainly on how the
other handler functions operate)<br>
Actually, thinking back, the name for this function is probably not
the best...<br>
<br>
Of course, I am totally fine with contributing this patch.<br>
Though, I was just wondering if there is a show-stopper in
integrating it in the main code, since I provide an option to use
this behavior or not, and this is made as to not impact default
behavior. (Of course, this would add one config/environment flag
check per query at execution)<br>
<br>
Now, I do understand this is one feature you are not exactly keen
with in the first place, let alone provide support for it.<br>
However, if I can further brush up the code to make it seaworthy for
the main repository, I am fine with pulling in the effort.<br>
<br>
I understand a lot of Japanese users would be extremely thankful for
easy availability of this feature via their favorite distribution,
instead of manual building/packaging.<br>
(Of course, there would remain the option of applying the contrib/
patch at distro packaging level, like Debian and *BSD do, but this
would multiply efforts)<br>
<br>
Cheers,<br>
<br>
On 11/13/2014 06:10 PM, W.C.A. Wijngaards wrote:<br>
<blockquote type="cite">Hi Stephane,<br>
<br>
On 13/11/14 04:08, Stephane Lapie wrote:<br>
> Hello,<br>
<br>
> There was a post several days ago about AAAA filter, and
questions<br>
> about an implementation as a Python module by Christophe.<br>
<br>
>
<a class="moz-txt-link-freetext" href="https://unbound.net/pipermail/unbound-users/2014-October/003579.html">https://unbound.net/pipermail/unbound-users/2014-October/003579.html</a><br>
<br>
> I work at the same company as him (a Japanese ISP, which are
all <br>
> subjected to NTT's flaky practices with use of IPv6), and
have<br>
> been working with him on this issue.<br>
<br>
The patch looks to have nice clean code.<br>
<br>
If you are looking for feedback on the code, this is what I can
find:<br>
iterator.h, comment for fetch_a_for_aaaa is misleading: say that a<br>
subquery has been made for fetching A records. It now seems as if
the<br>
flag is set in the subquery, but it is set in the superquery (to
avoid<br>
asking twice).<br>
<br>
iterator.c, asn_processAAAAResponse: this routine can be
shortened, I<br>
think. After changing the super_iq->state and log_query_info
lines,<br>
it can simply return. However, the current code does not fail
either<br>
; it might be more 'optimal' and save the statemachine some work.<br>
<br>
Thank you for publishing the patch. Are you all right if I put
this<br>
patch in the source contrib/ directory to make it more easily<br>
available to the users?<br>
<br>
We don't provide support for the contrib material, but it may be<br>
useful for users in weird circumstances.<br>
<br>
Best regards,<br>
Wouter<br>
<br>
<br>
<br>
> To sum up the scenario we are trying to fix : - customers in
Japan<br>
> have a physical carrier (NTT in most cases) on top of which
they<br>
> get their own internet provider, to which they connect via
PPPoE.<br>
> In our case, we currently provide only IPv4 service at this
point <br>
> in time. - some customers also get an on-demand video service
via<br>
> his carrier, NTT, which give them a default IPv6 route via
IPoE, or<br>
> they raise a second PPPoE session (NTT usage terms allow for
up to<br>
> 2 sessions for this scenario). - the catch: said IPv6 default
route<br>
> does not go outside on the internet, and only enables access
to<br>
> NTT's closed network. Therefore, a customer in this
configuration<br>
> trying to access any IPv6 site is in for a world of pain as
his<br>
> browser times out and retries, hopefully fallbacking to IPv4.
This<br>
> prompted every Internet service provider in Japan to either
provide<br>
> native IPv6 or to filter AAAA records for "non-v6 only
sites",<br>
> which in this instance pretty much means everyone uses BIND.<br>
<br>
<br>
> To answer Bill Manning's earlier statement, "we can not
change <br>
> providers", first reason being because we ARE a provider, but
also <br>
> because even if we wanted to change carriers, everyone in
Japan is <br>
> entirely dependant on the majority physical carrier, i.e NTT.
Since<br>
> it happens at a lower layer than the ones we have control
over (we<br>
> work at PPPoE encapsulated level, they work at Ethernet
level), we<br>
> have no control whatsoever over said carrier-provided route,
short<br>
> of ourselves providing IPv6 service over or PPPoE and an
overriding<br>
> route, or via IPoE (and then tell NTT to buzz off and provide
our<br>
> route, if we had one). This is obviously scheduled as the
proper<br>
> solution, but requires overhauling all of the network<br>
> infrastructure, which can not be done instantly.<br>
<br>
> Also, thanks a lot to Daisuke Higashi for his statement,
using <br>
> "private-address/private-domain" is initially what we planned
on<br>
> doing, except this gets scary when we think about "what if
NTT<br>
> springs yet another domain on top of that, that we need to
allow<br>
> access to?" or "what if another customer tries to access yet<br>
> another IPv6-only site in the future?", and the
"whack-a-mole"<br>
> administration nightmare it might become.<br>
<br>
<br>
<br>
> In the meantime, we still need to get rid of BIND, which
can't<br>
> handle the resource exhaustion DDoS attacks <br>
>
(<a class="moz-txt-link-freetext" href="http://dnsamplificationattacks.blogspot.jp/2014/02/authoritative-name-server-attack.html">http://dnsamplificationattacks.blogspot.jp/2014/02/authoritative-name-server-attack.html</a>)<br>
<br>
<br>
we are seeing since february of this year. This is where we wanted
to go<br>
> with unbound, except since it does not have AAAA-filter<br>
> functionality, we could not use it in production for most of
our<br>
> customers.<br>
<br>
> This is where Christophe attempted to intercept queries with
Python<br>
> and we found out : - Python API does not enable to spawn sub<br>
> queries (for each AAAA query, the relevant A record has to
exist in<br>
> cache, for AAAA filter logic to work) - Python API does not
enable<br>
> to lookup RRset cache for a given record (in this case, for
an A<br>
> record matching the queried name) - Python API does not allow
for<br>
> easy scrubbing of packets (it IS possible, but very painful)<br>
<br>
<br>
<br>
> I therefore came to the conclusion that the Python API was
not <br>
> appropriate to do these things, and that the most appropriate
place<br>
> to implement a filtering/scrubbing logic was the iterator
module<br>
> itself.<br>
<br>
> I coded the following patch (also attached) : <br>
>
<a class="moz-txt-link-freetext" href="http://www.yomi.darkbsd.org/~darksoul/aaaa-filter-iterator.patch">http://www.yomi.darkbsd.org/~darksoul/aaaa-filter-iterator.patch</a>
It<br>
> has been on tests and running in pre-production for roughly a<br>
> month now (while undergoing some tuning as I got around to<br>
> understanding how the state machine works).<br>
<br>
> The patch provides : - a "aaaa-filter" config option which is
off<br>
> by default, so as to not be intrusive (I am fully aware this<br>
> functionality is enough of an abomination as is). It can also
be<br>
> used in conjunction to private-address/private-domain without
any<br>
> issues. - the relevant manual entry - modifications to<br>
> iterator/iter_scrub.c in scrub_sanitize() to remove AAAA
records<br>
> for queries that either are not AAAA type, OR that did return
an A<br>
> record, IF cfg->aaaa_filter is enabled. - modifications to<br>
> iterator/iter_utils.c to provide AAAA filter "on/off" info to
the<br>
> iterator environment. - modifications to iterator/iterator.c
: -- a<br>
> new ASN_FETCH_A_FOR_AAAA_STATE from which we branch into from
<br>
> QUERYTARGETS_STATE if this is a AAAA query (modifies<br>
> iter_handle(), iter_state_to_string(),<br>
> iter_state_is_responsestate(), -- asn_processQueryAAAA()
function<br>
> that throws a subquery and flags the parent query as "already<br>
> fetching an A subquery" so as to not loop -- modifications to<br>
> iter_inform_super() to handle the new state for AAAA parent
queries<br>
> having a A subquery. -- asn_processAAAAResponse() function
that<br>
> basically takes after what error_supers() and<br>
> processTargetResponse() do, except it does not alter target
queries<br>
> counters. - modifications to iterator/iterator.h :
declaration of<br>
> new flags for iter_env (configuration option), iter_qstate
(status<br>
> flag), and the new iter_state<br>
<br>
<br>
<br>
> At this point, the patch is pretty much stable and performing
as <br>
> expected, but I am looking for pointers as to stuff I could
improve<br>
> on that patch, especially style-wise, to ensure it is
applicable as<br>
> long as possible. In its current state, I can apply it up to<br>
> 1.4.22.<br>
<br>
> I also know from previous postings that unbound development<br>
> staff's opinion is that this functionality as a whole would
harm<br>
> IPv6 adoption, and therefore can probably not be officially<br>
> endorsed, but I still intend to provide it freely (my company
has<br>
> given approval) to people suffering from the same scenario.
(that<br>
> is, mainly Japanese users at this point...)<br>
<br>
> Thanks for your time,<br>
<br>
<br>
> _______________________________________________ Unbound-users<br>
> mailing list <a class="moz-txt-link-abbreviated" href="mailto:Unbound-users@unbound.net">Unbound-users@unbound.net</a> <br>
> <a class="moz-txt-link-freetext" href="http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users">http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users</a><br>
<br>
<br>
</blockquote>
<span style="white-space: pre;">>
_______________________________________________<br>
> Unbound-users mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Unbound-users@unbound.net">Unbound-users@unbound.net</a><br>
> <a class="moz-txt-link-freetext" href="http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users">http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users</a></span><br>
<br>
-- <br>
Stephane LAPIE, EPITA SRS, Promo 2005<br>
"Even when they have digital readouts, I can't understand them."<br>
--MegaTokyo<br>
<br>
<pre class="moz-signature" cols="72">--
Stephane LAPIE, EPITA SRS, Promo 2005
"Even when they have digital readouts, I can't understand them."
--MegaTokyo
</pre>
<br>
</body>
</html>