Name resolution does not work with IPv6 only name servers

[dnmvisser]

When only IPv6 name servers are listed in /etc/resolv.conf, name resolution does not work.

[Kevin Otte (nivex)]

Looking through the code, the first sign of trouble is in dns_open() on line 504:
  for (i = 0;i < myres.nscount;i++)
    myres.nsaddr_list[i].sin_family = AF_INET;
  resfd = socket(AF_INET, SOCK_DGRAM, 0);

Two assumptions that we will be dealing with v4 resolvers only.

Later, in dns_ack() on line 1253 we see more AF_INET used in comparing the response to make sure it was something we sent.

I presume handling DNS in this way was done so calls would be asynchronous. Could getaddrinfo_a() be employed instead to put some of the burden back on the system resolver library?

[Kevin Otte (nivex)]

My bad. getnameinfo() would need an async equivalent, of which there doesn't appear to be one.

[rew (r-e-wolff)]

Kevin, If you want you can rewrite mtr to use the system library. It
would be preferable if you would allow us to switch at runtime between
the two (or more) DNS resolver modules.

Design suggestions:
 -- modules. Allow easy replacement of a module by another one.
    First module is of course the existing async DNS module.
 -- (I don't think run-time-replaceable modules is useful, so just
    compile time modules is fine. This is already implemented in the
    output modules where you get to chose report, gtk or curses.)
 -- Getting to know the code: Just use the system DNS resolver
    function. This will "hang" mtr for seconds at a time when
    the resolv happens.
 -- The async version: fork a completely new process that does
    the name resolving and reports back.
     (the parent process can create a pipe, and have the children write
     to the pipe, so that one select on the pipe read end will give you
     if any of the resolves are finished.)
     This means that the writes need to include the resolved IP address
     as well as the results of the resolving. And to prevent races,
     you need to write those in one go.
       BAD:
            printf ("%s ", inet_ntoa(input_ip_address));
            printf ("%s\n", <the resolver result>);
       BETTER:
            printf ("%s %s\n", inet_ntoa(input_ip_address),
                    <the resolver result>);
       BEST:
            sprintf (mybuf, "%s %s\n", inet_ntoa(input_ip_address),
                    <the resolver result>);
            write (1, mybuf, strlen (mybuf));
    The children are probably very simple:

      if (pid == 0) {
         // call the resolver
         // print the result
         exit (0);
      }
    the parent is slightly more complex:
    // if not already done: create the pipe.

    Hmm. It seems easiest to just write to the write-end of the pipe,
    (instead of redirecting stdout as I had originally thought)
    so the printf's become "fprintf's" but easiest is to just use
    the "BEST" option and write to the resolver_pipe[1].

    so all in all it should become something like:

    static int resolverpipe[2];
    if (!resolverpipe[0]) {
       pipe(resolverpipe);
       // check for error return;
    }
    if (!fork ()) {
       // prepare "node" field.
       getaddrinfo (node, ..., res);
       sprintf (mybuf, ...);
       write (resolverpipe[1], mybuf, strlen (mybuf));
       exit (0);
    }

    that needs to be integrated into mtr....

--
** <email address hidden> ** http://www.BitWizard.nl/ ** [phone] **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

[Ask Bjørn Hansen (askbjoernhansen)]

Wouldn't it be simpler to replace the async dns code with a library that supports IPv6? (c-ares for example – http://c-ares.haxx.se/ )

[Antonio Querubin (aaq)]

When I added IPv6 support to MTR a while back I left out support of IPv6 nameservers for expediency. Now that I'm running some servers in an IPv6-only environment this is now a real issue. Attached are patches that address this (sorry for the several years of delay).

So far, this has been tested on Scientific Linux 6.3 only. I no longer have a BSD type environment in which to test, nor do I have have a current version of Mac OSX either.

[dnmvisser (dnmvisser)]

Thanks!!!! Will this patch be integrated into future Ubuntus?

[Antonio Querubin (aaq)]

I had some time to update the IPv6 DNS patch to work under FreeBSD 9.0. Note that portability to other BSD-type systems depends on finding where the __res_state_ext struct is actually defined.

[Antonio Querubin (aaq)]

This update is a bit cleaner and doesn't require system sources.

[Antonio Querubin (aaq)]

Built and tested patch on Ubuntu 12.04 and Debian 6.0.

[Antonio Querubin (aaq)]

Built and tested on openSUSE 12.2.

[rew (r-e-wolff)]

Can someone tell me how to test this from my IPV4 end of the internet? I guess I can't

[dnmvisser (dnmvisser)]

You could install a local DNS server and then add the IPv6 localhost address (::1) as the resolver.

[Antonio Querubin (aaq)]

On Wed, 6 Feb 2013, rew wrote:

> Can someone tell me how to test this from my IPV4 end of the internet? I
> guess I can't

You could get yourself an IPv6 tunnel via one of the tunnel brokers (eg.
Hurricane Electric). The actual test is to only use IPv6 addresses
(reachable from your network) in /etc/resolv.conf

Antonio Querubin
e-mail: <email address hidden>
xmpp: <email address hidden>

[Patrick Velder (patrick2)]

this bug is still present in 0.82 on debian 7.

[Antonio Querubin (aaq)]

On Thu, 3 Apr 2014, Patrick Velder wrote:

> this bug is still present in 0.82 on debian 7.

mtr is at version 0.85+

Antonio Querubin
e-mail: <email address hidden>
xmpp: <email address hidden>

[Haw Loeung (hloeung)]

I think the fix is in commit 0cc9f56313eb9329f1af870b35d63d1d04c9258f which was made on the 20th June (https://github.com/traviscross/mtr/commit/0cc9f56313eb9329f1af870b35d63d1d04c9258f)

[Haw Loeung (hloeung)]

Nope, looks like commit 0cc9f56313eb9329f1af870b35d63d1d04c9258f doesn't fix it either.

Seems mtr uses _res.nscount in dns_open() and that returns 0 on my system which only has IPv6 nameservers listed in /etc/resolv.conf.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Adds IPv6 nameserver support." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Haw Loeung (hloeung)]

Hi,

I've submitted a pull request on GitHub[1] with a fix to upstream as well as to the Ubuntu package. Package with updated fix also published on my Test PPA (ppa:hloeung/test).

[1]https://github.com/traviscross/mtr/pull/56

[Raoul Bhatia (raoul-bhatia)]

On Ubuntu Vivid,
mtr-tiny 0.85-3 crashes without any proper output when having IPv6 only nameservers.

It crashes in such way,
that i need to issue a "reset" to get the terminal back into a sane state.

Kindly see my attachment.

[Haw Loeung (hloeung)]

I looked into this a while back, because like you Raoul, I'm running on a system with only IPv6 resolvers.

It seems to be a bug in upstream glibc, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528992#44

"""
It seems that the change in submitted-resolv-ipv6-nameservers.diff[1]
is causing a regression with the mtr package (and probably other
packages).

The change in question is for statp->nscount to now only count IPv4
nameservers. This now causes mtr to fail on systems where only IPv6
nameservers are specified.
"""