Here I found some router hostnames in traceroute:
...
3 10.30.31.1 10.30.31.1 1.271
4 46.33.68.129 ae1-1989.cr4-ams2.ip4.gtt.net 2.697
5 213.200.117.58 ae15.cr6-ams1.ip4.gtt.net 2.098
6 80.231.85.162 80.231.85.162 1.77
...
However, I could not get the IP associated with those hostnames with nslookup.
$ nslookup ae15.cr6-ams1.ip4.gtt.net
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find ae15.cr6-ams1.ip4.gtt.net: NXDOMAIN
I tried using dig +trace, but it didn't work.
$ dig ae15.cr6-ams1.ip4.gtt.net +trace
...
ip4.gtt.net. 300 IN NS pns.tinet.net.
ip4.gtt.net. 300 IN NS sns.tinet.net.
;; Received 96 bytes from 172.64.33.169#53(glen.ns.cloudflare.com) in 199 ms
ip4.gtt.net. 300 IN SOA pns.tinet.net. netguard.tinet.net. 2024060604 86400 7200 3600000 300
;; Received 109 bytes from 213.200.89.94#53(pns.tinet.net) in 215 ms
It stopped at ip4.gtt.net.
So why can't I resolve the router hostname? How can I do this?
Like most IP packets, traceroute packets don't really indicate the router's hostname in any way; they just have its IP address. Instead, the traceroute program has to look up hostnames from the IP address using a special DNS query – i.e. it shows the "reverse DNS" lookup results, and those are managed separately and stored in a completely separate place from regular domain information.
Due to the distributed nature of DNS, you can't really do an actual reverse query (i.e. it's impossible to find all domain names that point to an IP address) – nor would that be wise to allow even if it were possible – so instead the 'reverse DNS' data is stored as regular (forward) records under a special domain (.in-addr.arpa or .ip6.arpa) indexed by IP address, and updates to this information are independent from any "normal" domain ownership.
This means that if someone wants their "domain→IP" and "IP→domain" to match, they need to manually keep the DNS information in sync in two separate places (which, in a large ISP, are most likely managed by entirely different teams).
And on the other hand, if someone doesn't necessarily care about it, they can simply not do the "forward" DNS update – e.g. in cases like this, the actual network engineers probably don't care about "forward" DNS lookups working since they already have a whole network management database at hand, so they've only added the "reverse" data so that it shows up in traceroute and that's it.