Re: FYI: DNSOPS presentation

[Joel Jaeggli <joelja@bogus.com>]

On 04/02/2010 11:11 AM, james woodyatt wrote:
> On Apr 2, 2010, at 08:16, Brian E Carpenter wrote:
>> 
>> I do think that Google's solution to this, i.e. being selective 
>> about who gets the AAAA records in the first place, is much less of
>> a hack, with less harmful side effects.
> 
> While everyone else was in the 6MAN session, I was actually jumping
> back and forth between 6MAN and DNSOP because I didn't want to miss
> this presentation.  As I pointed out at the microphone in DNSOP, the
> proposed hack is absolutely broken because it relies on a pair of
> TOTALLY INOPERATIVE ASSUMPTIONS:
> 
> A) good IPv6 connectivity between the DNS resolving server and the
> DNS content server implies good IPv6 connectivity between the client
> application host and the application server host.
>
> B) good IPv6 connectivity between the client application host and the
> application server host requires good IPv6 connectivity between the
> DNS resolving server and the DNS content server.

actually they don't rest on those assumptions.

the assumption being made is that queriers who are customers of a given
set of name-servers have available to them a particular kind of
connectivity...

this is exactly the same kind of assumption made when selectively
returning different A records in an ipv4 global loading balancing setup.

The consequences of getting it wrong in ipv4 are you go to a more
distant instance of a service.

The consequence of getting it wrong in ipv6 are you hand a AAAA record
to a host that doesn't use it (this causes no harm) or you hand a AAAA
record to host that shouldn't use it (because soemthing about their
connectivity is broken). presumably the decision to make a particular
set of queriers as blessed for the purpose of reciveing AAAA records is
based on a judgement about the likelyhood of the hosts behind that
resolver being non-broken.

> The obvious illustration that comes to mind is a host behind an Apple
> AirPort Extreme base station at a public IPv4 address and configured
> in 6to4 tunnel mode, but in a domain where the 6to4 relay service is
> unreliable, badly-impaired or black-holed, and also configured to
> forward its DNS queries to resolving servers that are dual-stack
> IPv4/IPv6 capable.  This configuration is sufficiently common that
> any proposed solution to the problem must have an answer for it, and
> the proposed solution doesn't deal with it at all.
> 
> Shorter james: the proposed hack cannot solve the problem it intends
> to solve, and it breaks other networks that work fine today.  It
> should not be endorsed.
> 
> 
> -- james woodyatt <jhw@apple.com> member of technical staff,
> communications engineering
> 
> 
>