Provide more accurate reverse DNS results

[cypherpunks]

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

[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?

[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?

[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.

[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

[iwakeh]

Planned to be part of the first Onionoo release.

[iwakeh]

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

[karsten]

Make an summary more accurate (at least).

[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.

[irl]

Some relevant discussion happened at #25551.

[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)

[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.

[irl]

Adding metrics-team to cc