Reply from “nsa.gov” while pinging “gen.lib.rus.ec”

Question

Running ping gen.lib.rus.ec (a Library Genesis server) returns this output:

PING gen.lib.rus.ec (91.200.14.96) 56(84) bytes of data
64 bytes from nsa.gov (91.200.14.96): icmp_seq=1 ttl=57 time=69.1 ms

Why nsa.gov?

Answer 1

It is a joke :)

What you are seeing is the PTR record for 96.14.200.91.in-addr.arpa, otherwise known as the reverse dns for ip 91.200.14.96.

The reverse records for ip-adresses are delegated to the owners, and they can set the response to be whatever they like.

If you run the command: dig -t PTR +trace 96.14.200.91.in-addr.arpa, you can see which nameserver that have configured the PTR/Reverse DNS-record.

The output is truncated for readability:

14.200.91.in-addr.arpa. 172800  IN  NS  ns1.vhoster.net.
14.200.91.in-addr.arpa. 172800  IN  NS  ns2.vhoster.net.
14.200.91.in-addr.arpa. 3600    IN  NSEC    140.200.91.in-addr.arpa. NS RRSIG NSEC
14.200.91.in-addr.arpa. 3600    IN  RRSIG   NSEC 8 5 3600 20180518163550 20180418153550 23854 91.in-addr.arpa. SZdra/lg7c9+Arxp2hgfd3DvB2T0KMmxfSm6rzsGtLbuGPc5PEnYZPI7 qP5qoqpNXQXbNYxBKIKZn/3Q3ijPSoZZhbr83ABf9SLjuVswvSY1Wrrr dzu7bbLWxjIKe6U7tN+57LqgfY71dHVO8chaZAHwoj0JAxBnVbiLqUvD E5Y=
;; Received 321 bytes from 193.0.9.5#53(pri.authdns.ripe.net) in 10 ms

96.14.200.91.in-addr.arpa. 3600 IN  PTR nsa.gov.
14.200.91.in-addr.arpa. 3600    IN  NS  ns2.vhoster.net.
14.200.91.in-addr.arpa. 3600    IN  NS  ns1.vhoster.net.
;; Received 122 bytes from 91.200.14.2#53(ns1.vhoster.net) in 47 ms

As you can see, the answer is coming ns1.vhoster.net, which is responsible for the PTR-record for 91.200.14.96.

There are many other interesting reverse records in the 91.200.14.0/24 range:

12.14.200.91.in-addr.arpa domain name pointer disney.com.
61.14.200.91.in-addr.arpa domain name pointer bot.4.
251.14.200.91.in-addr.arpa domain name pointer whitehouse.gov.

Check all of them here

Can this be a security problem? Yes, potentially. If the reverse-dns is not threated as untrusted input, it can lead to different problems.

• If an application only log connections based on PTR-records instead of IP-address, you lose traceability.
• If the reverse-dns is used as part of an SQL-command, it might be used to conduct an sql-injection attack.
• If used in HTML-documents, unsanitized PTR-records can be used for HTML-injection/XSS attacks.