Name resolution does not work with IPv6 only name servers

Bug #752583 reported by dnmvisser
80
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Mtr
Fix Released
Medium
Unassigned
mtr (Debian)
Confirmed
Unknown
mtr (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

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

Tags: ipv6

Related branches

Changed in mtr (Debian):
status: Unknown → New
Revision history for this message
Kevin Otte (nivex) wrote :

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?

Revision history for this message
Kevin Otte (nivex) wrote :

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

Revision history for this message
rew (r-e-wolff) wrote : Re: [Bug 752583] Re: Name resolution does not work with IPv6 only name servers

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/ ** +31-15-2600998 **
** 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.

Revision history for this message
Ask Bjørn Hansen (askbjoernhansen) wrote :

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/ )

Revision history for this message
Antonio Querubin (aaq) wrote :

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.

Revision history for this message
dnmvisser (dnmvisser) wrote :

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

Revision history for this message
Antonio Querubin (aaq) wrote :

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.

Revision history for this message
Antonio Querubin (aaq) wrote :

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

Samuel Bronson (naesten)
Changed in mtr:
status: New → Confirmed
Changed in mtr (Debian):
status: New → Confirmed
Revision history for this message
Antonio Querubin (aaq) wrote :

Built and tested patch on Ubuntu 12.04 and Debian 6.0.

Revision history for this message
Antonio Querubin (aaq) wrote :

Built and tested on openSUSE 12.2.

rew (r-e-wolff)
Changed in mtr:
status: Confirmed → Fix Committed
Revision history for this message
rew (r-e-wolff) wrote :

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

Changed in mtr:
importance: Undecided → Medium
Revision history for this message
dnmvisser (dnmvisser) wrote :

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

Revision history for this message
Antonio Querubin (aaq) wrote :

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>

rew (r-e-wolff)
Changed in mtr:
status: Fix Committed → Fix Released
Revision history for this message
Patrick Velder (patrick2) wrote :

this bug is still present in 0.82 on debian 7.

Revision history for this message
Antonio Querubin (aaq) wrote :

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>

Revision history for this message
Haw Loeung (hloeung) wrote :

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

Revision history for this message
Haw Loeung (hloeung) wrote :

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.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

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.]

tags: added: patch
Haw Loeung (hloeung)
tags: removed: patch
Revision history for this message
Haw Loeung (hloeung) wrote :

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

Changed in mtr (Ubuntu):
assignee: nobody → Haw Loeung (hloeung)
status: New → In Progress
Haw Loeung (hloeung)
Changed in mtr (Ubuntu):
assignee: Haw Loeung (hloeung) → nobody
Revision history for this message
Raoul Bhatia (raoul-bhatia) wrote :

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.

Revision history for this message
Haw Loeung (hloeung) wrote :

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.
"""

Haw Loeung (hloeung)
Changed in mtr (Debian):
importance: Unknown → Medium
Changed in mtr (Ubuntu):
status: In Progress → Confirmed
importance: Undecided → Medium
Changed in mtr (Debian):
importance: Medium → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.