<div dir="ltr">On Tue, Jul 1, 2014 at 1:43 PM, Tony Finch <span dir="ltr"><<a href="mailto:dot@dotat.at" target="_blank">dot@dotat.at</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thomas Schäfer reported an interesting bug on the ipv6-ops list:<br>
<a href="http://lists.cluenet.de/pipermail/ipv6-ops/2014-July/010032.html" target="_blank">http://lists.cluenet.de/pipermail/ipv6-ops/2014-July/010032.html</a><br>
<br>
The problem occurs when /etc/resolv.conf contains a link-local nameserver<br>
address, which necessarily includes a scope so that the address is<br>
associated with the correct interface.<br>
<br>
Some stub resolver libraries fail to parse the scope - usually they ignore<br>
the scope rather than failing, but this results in the wrong interface<br>
index in the eventual sockaddr, so the resolver ends up unable to talk to<br>
its server.<br>
<br>
The interestingly awkward thing about this bug is that it implies that you<br>
cannot use a simple IPv6 address (e.g. AAAA RDATA) to represent a stub<br>
resolver's name server addresses. Unfortunately the getdns API assumes<br>
that you can; to fix this it needs to learn about scoped addresses.<br>
<span class="HOEnZb"></span></blockquote><div><br></div><div>I agree we should fix this. Looks like getdns currently ignores the scope id.<br><br>Note that the default mode of operation of the getdns library is to do full recursion, so a scoped link-local address won't work anyway - the system needs at least one globally routable IPv6 address. This becomes an issue if you change the mode of operation to stub and there is an upstream resolver with a scope-id specified.<br>
<br></div><div>--Shumon<br><br></div></div></div></div>