Thoughts about ipv6 white listing

[Erik Kline]

On 4 December 2010 02:21, George Bonser <gbonser at seven.com> wrote:
> Rather than taking a white listing approach to v6, I thought I might do
> the following:
>
> Configure an instance of named that is v6 only.  That instance contains
> both A and AAAA records.  Register that DNS server in whois with a v6
> address only.  The instances of named running on v4 have a zone with
> only A records.
>
> Requests that arrive via v6 that request an AAAA resource are given one
> if one is available.
>
> Requests that arrive via v4 that request an AAAA resource are returned
> NXDOMAIN
>
> This *should* greatly reduce the number of requests where a client
> thinks it has v6 connectivity (has a local v6 LAN but no Internet v6 or
> can't reach me via their provider) getting an AAAA resource that it
> can't reach.  The reasoning being that if they reached me by v6 to
> request the resource, they can most likely also reach the resource
> itself.
>
> There will be a possibility where a client actually does have v6
> Internet and can actually reach me but their DNS server is v4 only.  I
> am willing to force those cases to fall back to v4.  This is sort of
> self white listing where the client, if requesting by v6 for a v6
> resource gets one and is likely to succeed in connecting.  There is the
> odd chance where the client has a v6 local net (ULA?) that is not
> globally routable *and* has a properly configured v6 dns server where I
> could get a v6 request that the client can't reach but my opinion is
> that it is a corner case that *needs* to break so that it can be fixed.
>
> Anyone else done anything like this?
>
> George
>
>

I have been thinking of something semi-similar, only using the draft
EDNS0 client ip/subnet option, i.e. returning AAAAs for any request
with EDNS0 client ip information indicating AF_INET6 && !(6to4 ||
Teredo).

I was then planning on passively auditing (via experimental
measurement probes) for resolvers that misrepresent their clients (or
perhaps are chaining so that the EDNS0 client ip data is not truly
that of the client), and queue them for review (or blacklisting).