Code change:
only returns the hostname, even when both and are set. Steps to reproduce the behavior: and . . should return the FQDN defined by and . The breakage happens when is used, which is now the default in NixOS after Stopping causes to return the correct value. reproduces the issue. It broke at , which is when became enabled by default. It's still broken on which is at time of writing. Possibly related issues:
This seems to happen because the resolution flow (when nscd is running) looks like: calls , which uses the nodename (), which is the short hostname then calls , which invokes the nss machinery gets the request and processes the request according to the NSS rules; on my NixOS system this is (from systemd) doesn't match (from systemd) does match, and returns a synthesized record; systemd internally determines the hostname for this using only the nodename, so unless the nodename is already the FQDN then we fail here, and it does this before checking /etc/hosts. I wonder if we can fix this by patching out the support in systemd-resolved for looking up the nodename, which will make it fall back to the result from /etc/hosts instead; on NixOS we can (probably) always assume that /etc/hosts will actually have the correct system hostname in it.
No, this is most likely We wanted to polish that PR in the next days, and once merged, bump our nixpkgs pin (and resurrect the upstreaming attempts). If you want, can you check if using nsncd from this PR fixes the problem for you?
Ah, actually, I think I'm just talking out of my ass. systemd-resolved seems to be able to cope with this properly when I query it over DNS, so it probably isn't to blame.
tests fail at that PR. Setting gets a successful build, which then passes the test in , but it fails on the test.
This is a pretty weird behavior. What's (likely) failing here is the IPv6 resolution of . The test does pass on some NixOS setup, like my desktop (and the Ubuntu CI) but does fail on my laptop. I'm still not sure what's happening, is present in . There's something wrong with some NixOS setup, it'd be nice to fix that as well. By any chance, did you disable systemd-resolved? Thanks for the heads up wrt. . I'll have a look today.
The behavior I described is from the Nix build environment. I used the nixpkgs derivation for nsncd and updated the source to the PR.

Related discussion:
text: rustPlatform.buildRustPackage rec { pname = "nsncd"; <del> version = "unstable-2022-11-14"; </del> <ins> version = "unstable-2023-10-26"; # https://github.com/twosigma/nsncd/pull/71 has not been upstreamed # to twosigma/nsncd yet. Using the nix-community fork in the # meantime. </ins> src = fetchFromGitHub { owner = "nix-community"; repo = "nsncd"; <del> rev = "47e580f1db99603df6e212a2e62f18cc970cef40"; hash = "sha256-Nv3MYZcuYgD66BAGs3Tg37s086HAGsaDBFvELqQF3Tk="; </del> <ins> rev =  "d6513421f420e407248c6d0aee39ae2f861a7cec"; hash = "sha256-PykzwpPxMDHJOr2HubXuw+Krk9Jbi0E3M2lEAOXhx2M="; </ins> }; <del> cargoSha256 = "sha256-c1L6nEUBHw1YegmoRrI3WU/bF80Nzbz13hsGlNyBR9o="; </del> <ins> cargoSha256 = "sha256-cUM7rYXWpJ0aMiurXBp15IlxAmf/x5uiodxEqBPCQT0="; </ins> meta = with lib; { description = "the name service non-caching daemon";