Reverse lookup no longer working

I’d previously reported a situation in which different servers on my network required different local domain names appended to be found by name - local, nexusnet.local, etc. For the last couple of days (that I’ve noticed - could have started earlier) finding servers by name does not work at all. Every query is met with an unknown host message. DHCP is working, and all servers that I’ve attempted to reach have static reservations by name only (no domain appended). The local domain name configured into LuCI is “local”.

(I know kresd mainly, not much Omnia or other resolvers.)

Hi @vcunat, all hosts are listed in /tmp/kresd.config. Address mappings and names are correct, including appended .local domain on all names. A few of my host names had caps in the dhcp assignments. I changed those to lower case and confirmed the change was reflected in /tmp/kresd.config. Unfortunately, the names I have been testing all contained only lower case, numbers and in some cases “-”.

I also have tested with /tmp/kresd.config added in the “Additional hosts files”. After restarting kresd, no change.

@vcunat Further testing indicates that there may be an issue in the code when the hostname includes “-”. I can ping servers on my network that have only letters and digits, even if letters other than the first character are caps.

I just tested some locally, both with 1.1.1 and 1.2.0-rc1, and “-” didn’t cause any problem for me. (I don’t have a Turris, though.)

Definitely is an issue on my Omnia. Hosts like up-01 do not resolve, while hosts like zeroP3 resolve fine. I show installed versions as follows:
knot-libdnssec 2.3.3-1
knot-libknot 2.3.3-1
knot-libzscanner 2.3.3-1
knot-resolver 1.1.1-11

@vcunat Correction - some hosts with “-” in the names are not resolving. I tried some in another server group, which do resolve. I need to check further here on my network. May have a different issue afoot.

@nexusnet: could it be that these are link-local IPv6 addresses, i.e. f:o:o:b:a:r%baz? They aren’t supported yet, I think.

Bafflement here! The set of servers not resolving are all named up-NN, where the first N is 0 and the second N is a digit 1 thru 9. All can be reached by ip address. All show up reliably on network scans. Verified that hostnames on the servers themselves are correct. I’ve rebooted one and re-tested. Still no resolution.

@vcunat none of these servers are listed in the active v6 leases. The only 3 hosts in that list are unrelated.

Can you see kresd logs? (I’m not sure how verbose they’re by default on Omnia.) There might be “[hint] loaded XY hints” somewhere in the beginning.

I don’t have a kresd-specific log file on my Omnia. Would it be located somewhere other than /var/log or named other than kresd.log? I’m following the system log in /var/log/messages. Grep didn’t find the word “hint” in the current log.

Hmm, so, kresd should be creating a socked somewhere :slight_smile: If you can connect to it, you can interact with it, e.g. on desktop I use nc -U tty/PID. Then hints.get() should list all the configured hints, which would be a nice thing to check first (then we can try more interaction).

The location will probably be /tmp/kresd/tty/$PID.

Omnia runs BusyBox with ash shell. The nc command doesn’t appear to support -U ("nc: bad address ‘-U’); only accepts [IPADDR PORT]. Using x.x.x.1 53, nc pauses then returns to the command prompt. Return code is 0. Does not appear to be accepting input. Using 127.0.0.1 has same result. Test are being run from the Omnia ash shell.

Added: Omnia offers a selection of “full versions” of some commands that can be optionally installed. Checked for NC, but it’s not in the available packages list. Also tested in bash (forked under ash), but no diff bc it was using the same nc command implementation.

It’s a unix-domain socket, not an IP one. There probably is a command available on Omnia for that, but I don’t know these things much. socat tty/$PID - also works on my desktop.

Some progress. Using socat tty/$PID stdout produces a > prompt. Function hints.get() produces answer “nil” and another > command prompt. Does this indicate that kresd is not getting a hint? :grinning:

NOTE for other readers: socat on Omnia/BusyBox requires two addresses. If used with only tty/$PID, it exits with an error stating such. The -h doesn’t tell you to use stdout. Tried it on a whim and it worked.

Oh, I’m sorry. By mistake I tested this on a different kresd version. The one currently on Omnia is unable to list the hints, but you can at least inspect them one-by-one, e.g.:
> hints[‘localhost’]
[1] => 127.0.0.1
[2] => ::1

I did provide two addresses above, though it might be hard to notice that the dash is part of the command.

Everything I’ve tried returns nil, including localhost and simply a newline (return key).

hints[‘localhost’]
nil

Is a newer version possibly available for installation on Omnia?

Only sources and DEBs are provided ATM, I think, as it’s just -rc1 version anyway.