Opened 2 years ago

Last modified 3 weeks ago

#18342 accepted defect

Provide more accurate reverse DNS results

Reported by: cypherpunks Owned by: irl
Priority: Medium Milestone:
Component: Metrics/Onionoo Version:
Severity: Normal Keywords: metrics-2018
Cc: tyseom, metrics-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

What DNS server does onionoo use for reverse DNS lookups to generate the host_name entries?

https://onionoo.torproject.org/details?search=SGGS

example, of onionoo's reverse lookup results for SG.GS relays, all IPs:

+----------+--------------+
| nickname | host_name    |
+----------+--------------+
| SGGSUK4  | 124.6.36.196 |
| SGGSHK0  | 124.6.32.230 |
| SGGSUK6  | 124.6.36.198 |
| SGGSUK0  | 124.6.36.230 |
| SGGSUK3  | 124.6.36.195 |
| SGGSUK7  | 124.6.36.199 |
| SGGSUK1  | 124.6.36.193 |
| SGGSUK8  | 124.6.36.200 |
| SGGSUK5  | 124.6.36.197 |
| SGGSUK2  | 124.6.36.194 |
| SGGSLAX0 | 124.6.40.230 |
| SGGSNYC0 | 124.6.44.230 |
| SGGSUK9  | 124.6.36.201 |
+----------+--------------+

compare that with
http://torstatus.blutmagie.de/index.php

Child Tickets

Change History (16)

comment:1 Changed 2 years ago by tyseom

Cc: tyseom added

comment:2 Changed 20 months ago by karsten

Here's how we're currently resolving addresses to domain names:

      String result = InetAddress.getByName(this.address).getHostName();

Are there better ways to do this?

comment:3 in reply to:  description Changed 20 months ago by cypherpunks

As of 2016-09-05 09:00 there are still about 37% (3233 out of 8592) of onionoo records without proper reverse DNS entries.

I assumed that the problem resides on the used upstream DNS server (more than the method to query it, since I thought that is a pretty standard procedure).

That is why I asked which DNS server you (onionoo.tpo) use:

Replying to cypherpunks:

What DNS server does onionoo use for reverse DNS lookups to generate the host_name entries?

comment:4 Changed 20 months ago by Sebastian

When discussing this bug, it was pointed out on IRC that these examples that were given in the original report are misconfigured. While the reverse dns for these IPs is set, forward entries don't exist. Perhaps this is an additional check that onionoo does (and I think it probably should do). The host uses hetzner's nameservers, but they can resolve the reverse dns just fine.

The TTL of the entries of those hosts is set to something very unreasonably low. If you are in any way responsible for the relays mentioned above, please fix their DNS config. This is not to say that there isn't a bug still somewhere in onionoo, but afaict, not for the hosts mentioned above.

comment:5 in reply to:  4 Changed 20 months ago by cypherpunks

Replying to Sebastian:

The TTL of the entries of those hosts is set to something very unreasonably low. If you are in any way responsible for the relays mentioned above, please fix their DNS config.

This ticket is not about rDNS entries of specific relays, these were merely examples, AFAIK these relays left the tor network a while ago:
https://lists.torproject.org/pipermail/tor-relays/2016-February/008807.html

While the reverse dns for these IPs is set, forward entries don't exist. Perhaps this is an additional check that onionoo does (and I think it probably should do).

If onionoo requires PTR and A DNS records to match please add that information to the description, currently it does not mention that in any way:

https://onionoo.torproject.org/protocol.html#details :

 host_name string optional

Host name as found in a reverse DNS lookup of the relay IP address. This field is updated at most once in 12 hours, unless the relay IP address changes. Omitted if the relay IP address was not looked up or if no lookup request was successful yet.

I care about rDNS records (even if PTR and A records don't match) because I'd like to use them for group detection for ornetradar and it is apparently very common that providers do not have A records for PTR records.
https://lists.riseup.net/www/info/ornetradar

comment:6 Changed 20 months ago by iwakeh

Milestone: Onionoo 3.1-1.0.0

Planned to be part of the first Onionoo release.

comment:7 Changed 18 months ago by iwakeh

Milestone: Onionoo 3.1-1.0.0Onionoo 3.1-1.1.0

The first Onionoo release should be kept small and as this seems still an open question I move this to the next milestone.

comment:8 Changed 16 months ago by iwakeh

Milestone: Onionoo 3.1-1.1.0

comment:9 Changed 7 months ago by karsten

Summary: onionoo has poor reverse DNS resultsProvide more accurate reverse DNS results

Make an summary more accurate (at least).

comment:10 Changed 7 months ago by karsten

Keywords: metrics-2018 added

comment:11 Changed 7 months ago by karsten

Owner: set to metrics-team
Status: newassigned

comment:12 Changed 5 months ago by irl

Java does indeed check to see that there is an A record that matches the PTR record when using InetAddress.getHostName().

The following would allow us to perform this "manually": https://docs.oracle.com/javase/8/docs/technotes/guides/jndi/jndi-dns.html

We could then flag whether or not the A record matched and return this information along with it.

comment:13 Changed 5 weeks ago by irl

Owner: changed from metrics-team to irl
Status: assignedaccepted

Some relevant discussion happened at #25551.

comment:14 Changed 5 weeks ago by cypherpunks

Ok, to summarize what I would like to see:

  • new field: dns_ptr Description: DNS PTR record of the relay's primary IP address. This field is updated at most once in 12 hours, unless the relay's primary IP address changes. Omitted if no lookup request was successful yet.
  • change the host_name implementation by doing what the current description says (#25551)

comment:15 Changed 5 weeks ago by irl

I really don't like the dns_ptr name for the field. I think Onionoo works at a higher level than that. I think I definitely prefer the unverified_host_name and host_name approach. To get the behaviour you're looking for in JavaScript would be:

dns_ptr = relay['host_name'] || relay['unverified_host_name'];

or Python:

dns_ptr = relay.get('host_name', None) or relay.get('unverified_host_name', None)

The approach where you have dns_ptr and host_name means that when correctly configured, the host name would end up included twice. I just don't feel that that's the most elegant solution.

I'll take a look at a patch for the spec later this week, but to outline:

  • For host_name we implement the spec as it is (actually omitting the field instead of returning IP addresses).
  • For unverified_host_name, this will include the DNS PTR record's name. It would be updated at the same time as the host_name record. Omitted if the host name was verified by looking up an A record, or if no PTR record was found.

comment:16 Changed 3 weeks ago by irl

Cc: metrics-team added

Adding metrics-team to cc

Note: See TracTickets for help on using tickets.