Nathan Ward <nanog@daork.net> writes:
...
Nice rant though
agreed.
...
Does anyone have info on how bind (and other recursive resolvers)
select whether to use v6 or v4 if an NS points at a resource with both
A and AAAA records? Most OSes prefer the AAAA record, does bind behave
the same?
yes.
Is this a configurable option for the inverse behavoir? Seems to me
that it should be since it affects the user experience and sets policy
for the network. It just may be, but I can't find the option if it is.
Best,
-M<
Is this a configurable option for the inverse behavoir? Seems to me
that it should be since it affects the user experience and sets policy
for the network. It just may be, but I can't find the option if it is.
If you have FreeBSD or Windows you can manipulate the "policy table" to make this happen.
It's a bit too complex to explain how this works in a post though, but try:
# ip6addrctl show
or
C:\>netsh
interface ipv6
netsh interface ipv6>show prefixpolicy
RFC 3484 provides background info. And of course any IPv6 book worth its salt explains it all in great detail. 
Further explanation and examples for XP, Windows 2003 and Vista also
available here:
http://www.ipv6tf.org/index.php?page=using/connectivity/guides&id=2
http://www.ipv6tf.org/index.php?page=using/connectivity/guides&id=1
http://www.ipv6tf.org/index.php?page=using/connectivity/guides&id=13
Regards,
Jordi
[ snip ]
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not the client.
The resolver should have an attribute to select the preference between
A vs. AAAA. Otherwise, it's setting network policy through code.
My question was if there is an option to adjust this, where is it? I
don't see it. I'm not a BIND uber-expert. If there is no option, there
quite possibly ought to be one.
Best,
Martin
I guess the question could also be asked as to whether BIND honours the host's configuration of the address selection policy - which seems more likely than implementing it itself.
For those who missed it - OS level address selection policy won't apply to BIND without specific code, as BIND is a recursive resolver so won't be calling getaddrinfo(3).
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not the client.
The resolver should have an attribute to select the preference between
A vs. AAAA. Otherwise, it's setting network policy through code.
How is using an address that is present "setting network policy"?
For those who missed it - OS level address selection policy won't apply to BIND without specific code, as BIND is a recursive resolver so won't be calling getaddrinfo(3).
(I missed that we were talking about BIND in my previous message, by the way. Sorry.)
Some quick experimentation suggests that BIND ignores the policy table and just round robins (or something that looks like it) through all available addresses. Try some different non-existing hostnames under kame.net, which has two NS records that both have an IPv4 address and one has one IPv6 address and the other one has two.
In article <ECD70626-8EB0-4651-8A3E-51D783571389@daork.net> you write:
[moresnip]
The way I read the portion of the thread related to resolver behavoir
was that the resolver behavior was being discussed. Not the client.
The resolver should have an attribute to select the preference between
A vs. AAAA. Otherwise, it's setting network policy through code.My question was if there is an option to adjust this, where is it? I
don't see it. I'm not a BIND uber-expert. If there is no option, there
quite possibly ought to be one.I guess the question could also be asked as to whether BIND honours
the host's configuration of the address selection policy - which
seems more likely than implementing it itself.For those who missed it - OS level address selection policy won't
apply to BIND without specific code, as BIND is a recursive resolver
so won't be calling getaddrinfo(3).--
Nathan Ward
named actually measures the response times to individual addresses
and uses those to determine which servers to query. Named also
uses what addresses it has before attempting to determine if there
are alternate addresses.
Address selection policies are kind of meaningless in this environment.
But what really trumps all of these is getting rid of firewalls
that don't handle EDNS queries. These along with nameservers that
fail to respond to EDNS queries slow up the resolution process much
more than picking a sub-optimal addresses to query.
Mark
How so? I think it's valuable to be able to decide for myself if I
want preference for AAAA or A. If I understand what I am reading, and
am properly recalling past threads here, this would seem important
since it affects the user experience.
As far as how it sets network policy goes, any time something sets a
preferred mode over other options and is not modifiable, it's akin to
setting policy. History has shown that most of us agree with this.
If I'm not interpreting this correctly, I'm all ears (eyes).
[ Note, I'm not making any assumption that anyone has set out to set
internet policy through software. ]
-M<
In article <2d106eb50710150849q350af366i21209801084f90a@mail.gmail.com> you write:
In article <ECD70626-8EB0-4651-8A3E-51D783571389@daork.net> you write:
>
>
>
>> [moresnip]
>>
>> The way I read the portion of the thread related to resolver behavoir
>> was that the resolver behavior was being discussed. Not the client.
>> The resolver should have an attribute to select the preference between
>> A vs. AAAA. Otherwise, it's setting network policy through code.
>>
>> My question was if there is an option to adjust this, where is it? I
>> don't see it. I'm not a BIND uber-expert. If there is no option, there
>> quite possibly ought to be one.
>
>I guess the question could also be asked as to whether BIND honours
>the host's configuration of the address selection policy - which
>seems more likely than implementing it itself.
>
>For those who missed it - OS level address selection policy won't
>apply to BIND without specific code, as BIND is a recursive resolver
>so won't be calling getaddrinfo(3).
>
>--
>Nathan Wardnamed actually measures the response times to individual addresses
and uses those to determine which servers to query. Named also
uses what addresses it has before attempting to determine if there
are alternate addresses.Address selection policies are kind of meaningless in this environment.
How so? I think it's valuable to be able to decide for myself if I
want preference for AAAA or A. If I understand what I am reading, and
am properly recalling past threads here, this would seem important
since it affects the user experience.As far as how it sets network policy goes, any time something sets a
preferred mode over other options and is not modifiable, it's akin to
setting policy. History has shown that most of us agree with this.If I'm not interpreting this correctly, I'm all ears (eyes).
[ Note, I'm not making any assumption that anyone has set out to set
internet policy through software. ]-M<
getaddrinfo() is based on the assumption that there is *not*
a cache response times etc. named builds such a cache. To
do that however it needs to actually query the addresses.
It also has to have all the addresses to make that
determination.
Named works with partial information rather than going out
and fetching complete information then making the query.
Doing that would slow down the resolution process.
Most applictions also make exactly one connection and making
sure that is optimal is useful. Named makes millions of
connections. It's a completely different class of application.
Named is also pretty much agnostic about whether IPv4 or
IPv6 transport is used. At the moment it still tends to
be IPv4 as there is very little AAAA glue even when there
are AAAA records for the nameserver.
Mark