Opened 6 years ago

Closed 5 years ago

#10468 closed defect (fixed)

Make DnsPort, IPv6, and AutomapHostsOnResolve work together

Reported by: nickm Owned by:
Priority: High Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client 024-backport automap dns ipv6
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

From #10465: I started Tor with "./src/or/tor -dnsport '9999 preferipv6automap' -automaphostsonresolve 1 -automaphostssuffix . "

Then I did:

[619]$ dig @localhost -p 9999 aaaa www.torproject.org

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

;; QUESTION SECTION:
;www.torproject.org.		IN	AAAA

;; ANSWER SECTION:
www.torproject.org.	60	IN	A	127.237.144.204

;; Query time: 0 msec
;; SERVER: 127.0.0.1#9999(127.0.0.1)
;; WHEN: Sun Dec 22 09:19:54 2013
;; MSG SIZE  rcvd: 52

and

[621]$ dig @localhost -p 9999 example.com

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

;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		60	IN	A	127.201.101.133

;; Query time: 0 msec
;; SERVER: 127.0.0.1#9999(127.0.0.1)
;; WHEN: Sun Dec 22 09:20:31 2013
;; MSG SIZE  rcvd: 45

It seems to be sending A even if it was asked for an AAAA.

(There are deeper DNSPort+IPv6 issues going on, of course, but this part is probably easier, and it's an independently useful bit of functionality.)

See #10465 notes for more

Child Tickets

Change History (9)

comment:1 Changed 6 years ago by cypherpunks

Priority: normalmajor

This may be a security-sensitive bug, as various client resolver libraries may log invalid responses such as this. Information about DNS queries being done by the client, then, leak into the client's system log. As such, this should probably be fixed sooner.

For instance FreeBSD generates log messages such as:

Jan 23 05:18:25 host curl: gethostby*.getanswer: asked for "ifconfig.me IN AAAA", got type "A"
Jan 23 05:18:43 host wget: gethostby*.getanswer: asked for "ifconfig.me IN AAAA", got type "A"

comment:2 Changed 5 years ago by nickm

Status: newneeds_review

Branch "bug10468_024" in my public repository has a fix that works for me.

comment:3 Changed 5 years ago by andrea

I think this looks okay, but lemme make sure I understand all this:

1.) We get a request for an A or AAAA record

2.) We need to make sure the answer is the same record type and the local transparent proxy IP we return is the right address family.

3.) We need to set up mapping so that when we get incoming TCP connections on that IPv4 or IPv6 address we just returned, we send it the right place.

4.) Now here's the slightly tricky case that I'm not 100% sure what we actually do without looking deeper: does the address family of the local transparent proxy IP and the original DNS request have to match the address family on the exit side?

  • I.e., suppose a server (say, bar.foo.com) somewhere is IPv6 only and offers only AAAA records, not A records. Suppose we have transparent proxying and a client only supports IPv4, and requests an A record for bar.foo.com from our DNSPort.
  • What do we return, and what does the mapping we set up remember about it? How would the behavior differ if the server had both A and AAAA records?

comment:4 Changed 5 years ago by nickm

So the question is, what happens when we have automaphostsonresolve set to return A records, and we're connecting to foo.bar.com that only has an AAAA record?

The answer is, nothing bad, I believe. Locally, when the resolve happens, we pick a new 127.192.x.y address, and map that address to foo.bar.com. We store the mapping bidirectionally; see addressmap.c for the details. Then later when we get a connection attempt to 127.192.x.y, we rewrite that as foo.bar.com, and send a BEGIN cell with foo.bar.com in it. The parameters for whether that connection is allowed to be IPv4 or IPv6 depend on the settings of the port used to connect to 127.192.x.y, not the one that resolved foo.bar.com.

comment:5 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.4.x-final

andrea says it looks ok now. Merging to master and marking for possible backport.

comment:6 Changed 5 years ago by nickm

Recommendation: no backport because not a regression. Stupid bug though.

comment:7 Changed 5 years ago by arma

Summary: Make DnsPort, IPv6, and AutomapHostsOnResolve work tother.Make DnsPort, IPv6, and AutomapHostsOnResolve work together

comment:8 Changed 5 years ago by arma

'no backport' sounds good to me. Yay, a newly working feature.

comment:9 Changed 5 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final
Resolution: fixed
Status: needs_reviewclosed

Right. Also, it turns out that without the fix for #8380, this is less awesome than I had thought.

Note: See TracTickets for help on using tickets.