DNS issue with Atlas or with the ISP?
RIPE Atlas Web site displays a lot of "undefined" for the tests in AS 3125. See for instance <https://atlas.ripe.net/measurements/22766270/#!probes> or <https://atlas.ripe.net/measurements/22766942/#!probes> But the DNS resolution from this AS seems to work. Checking the raw results in JSON, I see that we have a lot of failures on one IPv6 resolver: "dst_name": "fe80::a63e:51ff:fe77:e26", "error": { "socket": "connect failed Invalid argument" }, We do not see such IPv6 problem in other AS (see for instance <https://atlas.ripe.net/measurements/22766995#!probes>) 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? Even if it is so, is it a good idea for the Atlas Web site to display "undefined" where the raw results show that other resolvers worked?
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?
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
On Mon, Sep 09, 2019 at 12:25:38PM +0200, Bjørn Mork <bjorn@mork.no> wrote a message of 42 lines which said:
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.
I agree that it is risky, but I'm not the CTO of this specific ISP... Anyone knows an example of another big ISP doing that? Also, there is a *rumor* (not substantiated by hard facts) that DNS resolution at this ISP experiences trouble, but I have currently no solid proof. (I was trying to use the Atlas probes for that.)
On 2019/09/09 9:39 , Stephane Bortzmeyer wrote:
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?
I just tried a bare link local address with dig on FreeBSD and it failed. For some reason my attempts on a few linux VMs failed for completely different reasons. The problem is that for a link local address you need a scope. The Atlas measurement code doesn't know how to add one and the addresses in /etc/resolv.conf don't have one. I sort of knew that this was going to be a problem, but link local for the resolvers seems to be quite rare. I'll make a note to see if I can make it work somehow. Philip
On Mon, Sep 09, 2019 at 01:06:48PM +0200, Philip Homburg <philip.homburg@ripe.net> wrote a message of 20 lines which said:
The problem is that for a link local address you need a scope. The Atlas measurement code doesn't know how to add one and the addresses in /etc/resolv.conf don't have one.
I was, too, surprised that it works but some people tested with dig or drill (I assume it was on monohomed machines, which is the case of RIPE Atlas probes) and it worked. Note that RFC 8106 explicitely authorizes it: 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.
participants (3)
-
Bjørn Mork -
Philip Homburg -
Stephane Bortzmeyer