#25551 closed defect (duplicate)

host_name field does not match spec

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

Description

https://metrics.torproject.org/onionoo.html#details_relay_host_name

Host name as found in a reverse DNS lookup of the relay's primary 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, if no lookup request was successful yet, or if no A record was found matching the PTR record.

There are many relays for which the host_name field contains the IP address, and there will be no A record for IP addresses, so the spec does not match what onionoo does? There are only 2 relays for which onionoo does not provide the host_name field.

tickets about the same field (but not the same issue): #18342

Child Tickets

Change History (6)

comment:1 Changed 13 months ago by karsten

Cc: irl metrics-team added

irl, mind taking a look?

comment:2 Changed 13 months ago by irl

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

Moving into my queue.

comment:3 Changed 13 months ago by irl

Either we should detect cases where a lookup failed and actually omit the field, or make clear that an IP address will be returned in the event the lookup fails. I agree that currently we do not implement what we said we implement in the spec.

cypherpunks: As you've raised the issue, do you have a preference on what we do to fix it?

I think I would like to have two fields: "unverified_host_name" and "host_name". If the forward lookup fails but we did look up a reverse record then we put that in "unverified_host_name". If everything works we put it in "hostname" and if no reverse record is found we omit both fields. This would be similar to the way we split up alleged family and effective family where we still report values even if they cannot be confirmed (and can use this information to tell the relay operator how to improve their configuration).

comment:4 Changed 13 months ago by irl

Status: acceptedneeds_information

comment:5 in reply to:  3 ; Changed 13 months ago by cypherpunks

Replying to irl:

Either we should detect cases where a lookup failed and actually omit the field, or make clear that an IP address will be returned in the event the lookup fails.

There are cases where you omit the field so I'm not sure what the current implementation actually does - that is why I created this ticket.

cypherpunks: As you've raised the issue, do you have a preference on what we do to fix it?

I've no strong opinion here but I like the "unverified_host_name" (I would name it dns_ptr to be more clear), but that goes in the direction of #18342.

The obvious thing to do would be do implement what the description says.

I think I would like to have two fields: "unverified_host_name" and "host_name". If the forward lookup fails but we did look up a reverse record then we put that in "unverified_host_name". If everything works we put it in "hostname" and if no reverse record is found we omit both fields. This would be similar to the way we split up alleged family and effective family where we still report values even if they cannot be confirmed (and can use this information to tell the relay operator how to improve their configuration).

For someone just interested in the PTR record this complicates things. If you name it dns_ptr you could always include it no matter if it PTR+A matches.

comment:6 in reply to:  5 Changed 13 months ago by irl

Resolution: duplicate
Status: needs_informationclosed

Replying to cypherpunks:

For someone just interested in the PTR record this complicates things. If you name it dns_ptr you could always include it no matter if it PTR+A matches.

There will be other things that look for a forward record before giving a PTR, and so a misconfigured forward or reverse zone may result in others finding no result when they make a query. I wouldn't want to not have some sort of clear distinction between a properly configured DNS setup and a not properly configured setup, especially when this could be the difference between an exit operator being harassed or not.

Let's call this a duplicate of #18342 and discuss this further there.

Note: See TracTickets for help on using tickets.