Opened 5 years ago

Last modified 2 months ago

#11625 new defect

Tor DNSPORT returns NXDOMAIN for AAAA records?

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.5.4-alpha
Severity: Normal Keywords: tor-client, dns, exit-node-choice, ipv6
Cc: mickeyc, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

On #11603, mickeyc reports:

Behaviour has changed with 0.2.5.4, but it is still broken. Now I'm getting an NXDOMAIN
 instead whenever I do any AAAA lookups. A record lookups are still fine:
mike@glue:~$ dig aaaa gmail.com @localhost -p 5304
; <<>> DiG 9.9.5-3-Debian <<>> aaaa gmail.com @localhost -p 5304
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19056
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;gmail.com. IN AAAA
;; Query time: 249 msec
;; SERVER: ::1#5304(::1)
;; WHEN: Sun Apr 27 11:37:35 BST 2014
;; MSG SIZE rcvd: 27
mike@glue:~$ dig +short a gmail.com @localhost -p 5304
173.194.70.18
mike@glue:~$

Child Tickets

Change History (9)

comment:1 Changed 5 years ago by nickm

Hm; it worked for me when I tried it just now:

[506]$ dig aaaa @localhost -p 9999 gmail.com

; <<>> DiG 9.8.3-P1 <<>> aaaa @localhost -p 9999 gmail.com
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31616
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com.			IN	AAAA

;; ANSWER SECTION:
gmail.com.		60	IN	AAAA	2a00:1450:4001:80e::1015

;; Query time: 542 msec
;; SERVER: 127.0.0.1#9999(127.0.0.1)
;; WHEN: Sun Apr 27 12:12:55 2014
;; MSG SIZE  rcvd: 55

Is there anything in your torrc?

I wonder if the behavior depends on what exit node you get? IIRC 0.2.3 exit nodes won't return AAAA records; I wonder if we're asking them anyway.

comment:2 Changed 5 years ago by mickeyc

I just repeated the test and it worked fine for me this time. I'm not sure why it didn't work last time, but I *did* repeat the test with several domains at the time, looking up both A records and AAAA records and seeing all of the AAAA record lookups NXDOMAIN. Perhaps it is down to the exit node in use, as you said.

comment:3 Changed 5 years ago by nickm

Keywords: lorax added
Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

Based on that diagnosis, this doesn't look like a must-fix-for-0.2.5 thing, especially given how over time more and more nodes will support IPv6 resolution. We can take a patch in 0.2.6 if somebody writes one.

comment:4 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 2 years ago by nickm

Cc: teor added
Keywords: exit-node-choice added; lorax removed
Severity: Normal

See also #10468 ; is this still happening?

comment:8 Changed 2 years ago by nickm

Keywords: ipv6 added

comment:9 Changed 2 months ago by blueyed

I am seeing this behavior currently (Tor version 0.3.4.11 (git-4fd31340f3355342)).

I wonder if the behavior depends on what exit node you get? IIRC 0.2.3 exit nodes won't return AAAA records; I wonder if we're asking them anyway.

Might this still be a reason by now?

I also wonder if this might be related to IPv6 not being configured (e.g. the machine has no inet6 address itself), since it has code like this in evdns_server_callback:

  /* This serves our DNS port so enable DNS request by default. */
  entry_conn->entry_cfg.dns_request = 1;
  if (q->type == EVDNS_TYPE_A || q->type == EVDNS_QTYPE_ALL) {
    entry_conn->entry_cfg.ipv4_traffic = 1;
    entry_conn->entry_cfg.ipv6_traffic = 0;
    entry_conn->entry_cfg.prefer_ipv6 = 0;
  } else if (q->type == EVDNS_TYPE_AAAA) {
    entry_conn->entry_cfg.ipv4_traffic = 0;
    entry_conn->entry_cfg.ipv6_traffic = 1;
    entry_conn->entry_cfg.prefer_ipv6 = 1;
  }

(It also looks like TCP is rejected (which is used with dig any, or explicitly via dig a +tcp @localhost example.com))

This is from the logs:

Apr 16 22:43:09.000 [info] {APP} evdns_server_callback(): Got a new DNS request!
Apr 16 22:43:09.000 [info] {APP} evdns_server_callback(): Passing request for "example.com" to rewrite_and_attach.
Apr 16 22:43:09.000 [info] {APP} evdns_server_callback(): Passed request for "example.com" to rewrite_and_attach_if_allowed.
Apr 16 22:43:09.000 [info] {CIRC,APP} exit circ (length 3): $XXX(open) $YYY(open) $ZZZ(open)
Apr 16 22:43:09.000 [info] {APP} link_apconn_to_circ(): Looks like completed circuit to $ZZZ~tortoise at 130.149.80.199 does allow optimistic data for connection to example.com
Apr 16 22:43:09.000 [info] {APP} connection_ap_handshake_send_resolve(): Address sent for resolve, ap socket -1, n_circ_id 2742445178
Note: See TracTickets for help on using tickets.