"gethostby*.getanswer" - what does it mean?

J

jamaroney

Starting a couple of weeks ago, I started getting this message many times every day:

Code: 
transmission-daemon 99225 - - gethostby*.getanswer: asked for "opentracker.i2p.rocks IN AAAA", got type "SOA"

What's going on? Is there anything I can do to prevent this?
 
It's a name resolve (DNS) request for the AAAA record (IPv6 address) of opentracker.i2p.rocks. But instead of an AAAA record it received a SOA record. In this case it means the i2p.rocks domain exists (that's what the SOA record shows) but it doesn't have an AAAA (IPv6) address record registered for opentracker.i2p.rocks.

Code: 
dice@molly:~ % drill opentracker.i2p.rocks AAAA
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 50351
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; opentracker.i2p.rocks.       IN      AAAA

;; ANSWER SECTION:

;; AUTHORITY SECTION:
i2p.rocks.      396     IN      SOA     ns1.i2p.rocks. ns2.i2p.rocks. 2024012401 3600 600 600 600

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.10.1
;; WHEN: Tue Mar 26 21:46:51 2024
;; MSG SIZE  rcvd: 83
There does exist an A (IPv4) record:
Code: 
dice@molly:~ % drill opentracker.i2p.rocks
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36745
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; opentracker.i2p.rocks.       IN      A

;; ANSWER SECTION:
opentracker.i2p.rocks.  3353    IN      A       23.137.251.46

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 2a02:a46e:550b:10::1
;; WHEN: Tue Mar 26 21:47:30 2024
;; MSG SIZE  rcvd: 55

If you have IPv6 enabled and working the system is going to prefer to connect with IPv6 first, if it doesn't exist (there's no IPv6 address registered) the system will fall-back to IPv4.
 
Thanks for this info, but I'm unsure what all that means.

I'm trying to determine why I started receiving these messages only recently when, to the best of my knowledge, no changes have occurred in my system. Is there anything I can do to eliminate the root of the problem (and thus the messages)? And why is it happening via Transmission?
 
SirDice said:
In this case it means the i2p.rocks domain exists (that's what the SOA record shows) but it doesn't have an AAAA (IPv6) address
Click to expand...
If you look closely at your drill(1) example, the ANSWER section is empty (as it should be when there's no record of the requested type). Getting a SOA record in the AUTHORITY section is expected. So I'd say something else is going wrong here, maybe some code just doesn't distinguish the sections in the response correctly...

jamaroney I would still ignore it. There's most likely nothing bad happening as a consequence. DNS lookups fail all the time, here it fails in a very weird way that might be a hint about a bug somewhere, but I'm pretty sure the client application doing this lookup can deal with it in the same way it can deal with any other failing DNS lookup.

edit: I quickly checked the behavior of my locally operated bind9:
  • Request for existing record: getting ANSWER and no AUTHORITY
  • Request for existing name but non-existing record type: no ANSWER, but AUTHORITY, and rcode NOERROR
  • Request for non-existing name (any type): no ANSWER, but AUTHORITY and rcode NXDOMAIN
What we see here is the second case, and this seems to be the "normal" server behavior, so something client-side indeed interprets it incorrectly.
 
You must log in or register to reply here.
Back
Top