Fully Qualified Domain Name

[DPArthur7212]

Did I research?

• I have searched the docs https://jokob-sk.github.io/NetAlertX/
• I have searched the existing open and closed issues
• I confirm my SCAN_SUBNETS is configured and tested as per https://github.com/jokob-sk/NetAlertX/blob/main/docs/SUBNETS.md

The issue occurs in the following browsers. Select at least 2.

• Firefox
• Chrome
• Other (unsupported) - PRs welcome
• N/A - This is an issue with the backend

What I want to do

Hi everyone,

I'm facing an issue with NetAlertX and could use some help. Here's the situation:

• During the first scan, a PC is detected with a name like "2025-PC01," and it’s added to my device list without any issues.
• After the first scan, I decide to rename the PC from "2025-PC01" to "2025-PC05" (e.g., because I made a mistake).
• On the next scan, the PC still appears in NetAlertX as "2025-PC01," even though running an NSLOOKUP command correctly returns the updated name "2025-PC05" (which makes sense since I changed the name).

I’ve tried tweaking the NSLOOKUP settings in NetAlertX (setting it to "always_after_scan" and "schedule" modes), but the device name still doesn’t update in the device list.

Am I missing something or doing something wrong? Any advice would be appreciated!

Thanks!

Relevant settings you changed

No response

docker-compose.yml

What installation are you running?

Production (netalertx)

app.log

No response

Debug enabled

• I have read and followed the steps in the wiki link above and provided the required debug logs and the log section covers the time when the issue occurs.

[jokob-sk]

Hi,

This is by design. The name in NetAlertX is treated as source of truth once detected. This is because most people update the metadata of their devices in NetAlertX. If scans would override user defined data this v would cause unintended data loss for most use cases.

Hope above makes sense.
J

[DPArthur7212]

Thanks for the explanation! I understand that NetAlertX treats the detected name as the source of truth to prevent unintended data loss. However, I’d like to propose an alternative approach that might better balance user control and automation:

• If the user manually edits the device name in NetAlertX, NSLOOKUP should respect that change and never overwrite the "name" field for that device. This ensures user-defined metadata is preserved, which makes perfect sense.
• If the user has not modified the device name, NSLOOKUP should automatically update the "name" field when a change is detected (e.g., via a new NSLOOKUP result). This would keep the device list accurate for cases where the name hasn’t been manually customized.

This approach would maintain the integrity of user-defined data while allowing NetAlertX to dynamically reflect network changes for devices that haven’t been manually configured. Wouldn’t this be a more intuitive and flexible solution for most use cases?

[jokob-sk]

Potential issues I see are:

• Device names come from multiple sources, not only from NSLOOKUP
• Keeping a history of names would mean to either check all possible plugins detecting names or a separate database field or table (expanding the schema is not trivial)
• Additional checks during scans will might slow down the app

This complexity might not be worth maintaining in the long term. This is the only time this feature request came up since the start of the project in 2021 as far as I remember.

I will keep this issue open for a few weeks in case this gathers more traction and to think about this a bit.

[jokob-sk]

I think the easiest thing would be to add a field called devLast[detected]Name which would show but be read only and keep the current devName functionality in tact. I'll sleep on it.

[DPArthur7212]

Thanks for the idea! Adding a read-only devLast[detected]Name sounds like a solid way to show the detected name without messing with devName. That already helps a lot for comparing names.

Just to add on — maybe there could be an option to auto-update devName, but only if the user hasn’t touched it manually. That way it stays simple, and if it’s just tied to NSLOOKUP, there’s no need to juggle multiple name sources, which keeps things cleaner. I get that it might need a bit more thought, though.

Anyway, the read-only field alone is already a great improvement. Keep us posted on what you decide, and thanks again for being open to feedback!