#21903 closed defect (fixed)

Disable DNS in chutney by default, and add an option to enable it

Reported by: teor Owned by: teor
Priority: Medium Milestone:
Component: Core Tor/Chutney Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: #19573 Points: 0.5
Reviewer: Sponsor:

Description

Due to #21900, we need to explicitly specify ServerDNSResolvConfFile /dev/null for chutney to work on macOS when the network is unavailable.

We should also set ServerDNSDetectHijacking 0.

This should be the default, because:

  • users who run chutney might not want it using DNS in a detectable pattern, and
  • it makes chutney more reliable, because it no longer depends on a working DNS.

Some users will want chutney to be able to use hostnames, so we should add a tools/test-network.sh option and environmental variable to re-enable the default ServerDNSResolvConfFile setting (or, even better, use a custom ServerDNSResolvConfFile).

There seems to be no reason to turn on ServerDNSDetectHijacking: some users might be using chutney with internal DNS names.

Child Tickets

TicketStatusOwnerSummaryComponent
#15353closednickmSome chutney tests fail when localhost is the only available IPCore Tor/Chutney
#16971closedTesting tor networks use external DNS for dns checksCore Tor/Tor
#21632closedteor"Couldn't set up any working nameservers. Network not up yet? Will try again soon."Core Tor/Chutney

Change History (10)

comment:1 Changed 20 months ago by teor

Parent ID: #19573

#19573 will use this option.

comment:2 Changed 20 months ago by teor

Status: newneeds_review

This is fixed in da1781e in my branch no-zombies:
https://github.com/teor2345/chutney/commits/no-zombies

Last edited 20 months ago by teor (previous) (diff)

comment:3 Changed 20 months ago by nickm

That commit seems plausible, though I do wonder why we're making DNS broken-by-default. Would it be better instead to have DNS work by default for chutney started from a command line, and have it disabled specifically when running tests that won't use it? (I'll believe either answer)

comment:4 in reply to:  3 Changed 20 months ago by teor

Status: needs_reviewneeds_information

Replying to nickm:

That commit seems plausible, though I do wonder why we're making DNS broken-by-default. Would it be better instead to have DNS work by default for chutney started from a command line, and have it disabled specifically when running tests that won't use it? (I'll believe either answer)

Due to Tor bug #21900, we have two choices:

  • make chutney work offline by default (but break DNS), or
  • allow DNS in chutney by default (but break offline use).

I don't mind which default we choose, as long as there is a way to flip it.
So I emailed tor-dev to see what other chutney users want.

comment:5 Changed 19 months ago by teor

This is now in no-dns-rebased

comment:6 Changed 19 months ago by teor

Status: needs_informationneeds_revision

I want DNS to work by default in chutney, and I want offline use to work even on macOS (and other OSs that have no resolv.conf).

I think a good way to fix this is to do the thing that will work once #21900 is fixed in tor.

So we should make working DNS the default, and have an --offline option.
(Or, even better, we could check if the ServerDNSResolvConfFile exists, and if it doesn't, we should apply a workaround, which can be switched off.)

comment:7 Changed 19 months ago by teor

Here's a design for this:

  • If the default ServerDNSResolvConfFile is missing, or is a symlink with a missing target (thanks, Apple!), chutney applies a workaround ServerDNSResolvConfFile /dev/null
  • An environmental variable can be used to set ServerDNSResolvConfFile
    • This can be used to implement --offline: CHUTNEY_DNS_CONF=/dev/null
    • This can be used to implement --dns-conf=X: CHUTNEY_DNS_CONF=X
  • An environmental variable can be used to not set ServerDNSResolvConfFile
    • This can be used to implement --dns-conf-default: CHUTNEY_DNS_CONF=""

To fix the crash on SETCONF in #21900, the user needs to supply a DNS conf with at least one nameserver.

To provide a conf that simultaneously:

  • works offline: CHUTNEY_DNS_CONF=/path/to/empty/or/working/conf
  • and doesn't crash on SETCONF: CHUTNEY_DNS_CONF=/path/to/conf/with/a/dns/server

The user must supply a local DNS server that gives the right answers to tor (#19573).
Or we can fix #21900, and just say /dev/null.
(We should document this in the chutney README.)

comment:8 Changed 18 months ago by teor

In #21989, arma suggests chutney uses ServerDNSDetectHijacking 0. That might solve some of these issues, but it certainly won't solve the eventdns breakage.

comment:9 Changed 18 months ago by teor

Rebased onto master as no-dns-rebased-v2.
Still need to add ServerDNSDetectHijacking 0 and implement --offline/--dns-auto/--dns-conf=path.

comment:10 in reply to:  7 Changed 15 months ago by teor

Resolution: fixed
Status: needs_revisionclosed

Implemented and merged to master as c889534.

Replying to teor:

Here's a design for this:

  • If the default ServerDNSResolvConfFile is missing, or is a symlink with a missing target (thanks, Apple!), chutney applies a workaround ServerDNSResolvConfFile /dev/null
  • An environmental variable can be used to set ServerDNSResolvConfFile
    • This can be used to implement --offline: CHUTNEY_DNS_CONF=/dev/null
    • This can be used to implement --dns-conf=X: CHUTNEY_DNS_CONF=X
  • An environmental variable can be used to not set ServerDNSResolvConfFile
    • This can be used to implement --dns-conf-default: CHUTNEY_DNS_CONF=""

This is implemented.

To fix the crash on SETCONF in #21900, the user needs to supply a DNS conf with at least one nameserver.

This is documented, and a local resolv.conf is provided by chutney.

To provide a conf that simultaneously:

  • works offline: CHUTNEY_DNS_CONF=/path/to/empty/or/working/conf
  • and doesn't crash on SETCONF: CHUTNEY_DNS_CONF=/path/to/conf/with/a/dns/server

The user must supply a local DNS server that gives the right answers to tor (#19573).
Or we can fix #21900, and just say /dev/null.
(We should document this in the chutney README.)

This is documented, but providing the right DNS answers is out of scope for chutney.

Note: See TracTickets for help on using tickets.