Opened 4 months ago

Closed 5 days ago

#33056 closed defect (wontfix)

Tor relays fail to understand /etc/resolv.conf ipv6 lines with % in them

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.4.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ipv6, libevent, 044-can
Cc: Actual Points:
Parent ID: Points: 1
Reviewer: Sponsor: Sponsor55-can

Description (last modified by arma)

We had a relay operator on irc just now who has this line in their /etc/resolv.conf:

nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0

Apparently this is a totally normal thing: the % indicates a link local name server.

Two more hints that % is a standard thing:

Tor is unable to handle this % syntax in a resolv.conf line:

Jan 25 17:03:00.171 [warn] eventdns: Unable to parse nameserver address fe80::7e2ebdff:fe99:4cb9%enp2s0

It's not as bad as it could be, because Tor skips that line and uses whatever other lines there are. But (a) maybe we're not doing as well as we can do, and (b) maybe there are situations where that's the only configured nameserver and everything works on the host except Tor doesn't.

I think technically this might be a libevent bug (aka missing feature), since it's libevent's evdns_base_nameserver_ip_add() which calls evutil_parse_sockaddr_port() which helpfully explains that

        /* recognized formats are:
         * [ipv6]:port
         * ipv6
         * [ipv6]
         * ipv4:port
         * ipv4
         */

none of which are the % syntax. But I will file it here as a Tor ticket, since it's a Tor bug too, and then we can figure out where best to fix it.

Child Tickets

Change History (7)

comment:1 Changed 4 months ago by arma

Description: modified (diff)

comment:3 Changed 4 months ago by arma

Good find!

So it sounds like some future release of libevent will have this feature, and so eventually relay operators will get it. Do we know what version of libevent that will be?

And in the meantime we at Tor have a choice about how we want to handle it. Here are some options:

(A) Do nothing, it was only one user, hope that common distros have the new libevent before it really starts to matter.

(B) Change Tor's error handling in the above log message, to check for a % character, and if it's present, say something more helpful, like that the warning is fine to ignore if they have other working nameservers, and if they really need that one, here's the version of libevent to upgrade to.

(C) Teach Tor to work around libevent's missing feature by somehow parsing the line ourselves or something.

I am fine with all three of these choices, and maybe there are other options to consider as well. Left to my own devices I would probably pick approach 'B'.

comment:4 Changed 4 months ago by teor

Keywords: libevent 044-should added
Milestone: Tor: 0.4.4.x-final
Points: 1

I don't think this change is urgent, so I'm triaging it into Tor 0.4.4.

It's also worth noting that:

  • tor exits need working DNS
  • tor non-exit relays and bridges only use DNS to discover their own address, and:
    • they are configured with a DNS name in the Address torrc option (failure is an error), or
    • their local hostname resolves via DNS (failure falls back to local interface APIs or directory X-Your-Address-Is headers)
  • tor clients don't depend on DNS for anything

comment:5 Changed 4 months ago by teor

Libevent seems to release every few months, so I think the answer to "when will there be a new libevent release" is "soon":
https://github.com/libevent/libevent/releases

Although I don't think this change was backported to libevent 2.1, so it might be a while before a new stable release:
https://github.com/libevent/libevent/branches

comment:6 Changed 6 days ago by asn

Sponsor: Sponsor55-can

comment:7 Changed 5 days ago by nickm

Keywords: 044-can added; 044-should removed
Resolution: wontfix
Status: newclosed

This is a libevent issue; we can't do anything about it on our end. The answer is "upgrade to a newer libevent when it is out."

Note: See TracTickets for help on using tickets.