Stephane Bortzmeyer <bortzmeyer@nic.fr> writes:
On Sun, Sep 08, 2019 at 06:53:12PM +0200, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 26 lines which said:
I assume that the "connect failed Invalid argument" is the fault of the ISP, which advertises a wrong DNS resolver? Or is the Atlas probe unable to query link-local addresses for DNS resolution?
So, people have tested, and confirm that 1) this ISP advertises link-local address via RA 2) it works with all DNS clients, but the RIPE Atlas probes. Any idea?
The first thing to sort out is if the probe RDNSS handler is RFC8106 compliant. For an LL address to work, we obviously need to know which link. And this means that the handler must know that LL addresses are special. Quoting https://tools.ietf.org/html/rfc8106#section-5.1 : Note: The addresses for RDNSSes in the RDNSS option MAY be link-local addresses. Such link-local addresses SHOULD be registered in the Resolver Repository along with the corresponding link zone indices of the links that receive the RDNSS option(s) for them. The link-local addresses MAY be represented in the Resolver Repository with their link zone indices in the textual format for scoped addresses as described in [RFC4007]. When a resolver sends a DNS query message to an RDNSS identified by a link-local address, it MUST use the corresponding link. I looked quickly at an old copy of networking/rptra6.c, and it doesn't look like it is doing this. I could be wrong or it could be fixed in a more recent probe firmware. But this is where I'd start to look. BTW, I seriously doubt that *all* other DNS and RDNSS clients got this right. Advertising LL DNS servers seems unnecessary risky outside of the lab. How much does a global IPv6 address cost these days? Bjørn