Inconsistent octal madness
$ ping 010
PING 010 (0.0.0.8) 56(84) bytes of data.
$ ping 010.1.1.1
PING 010.1.1.1 (8.1.1.1) 56(84) bytes of data.
$ ping 018
ping: 018: Name or service not known
$ ping 18
PING 18 (0.0.0.18) 56(84) bytes of data.
$ ping 018.1.1.1
PING 018.1.1.1 (18.1.1.1) 56(84) bytes of data.
$ ping 18.1.1.1
PING 18.1.1.1 (18.1.1.1) 56(84) bytes of data.
@bagder OK it looked consistent until the second to last one...
@astraleureka @bagder Random cursed guess: It's systemd making it do the wrong thing, via some cursed NSS module.
@dalias @astraleureka as mentioned elsewhere in this thread, it's my DNS that is "helpful"!
@bagder @astraleureka It's cursed that this is even making it to DNS...
@dalias @astraleureka it is actually a pretty weak design that an IP address with wrong syntax is instead treated as a hostname and just passed along instead of outright rejected.
@astraleureka @bagder Guess of mechanism: after resolving as a numeric address (rightly) fails with the standard processing, it gets passed on to next NSS backend in the order. Systemd (or something) has provided one which also resolves aaa.bbb.ccc.ddd (but not just aaaaaaaaaaaa form) to numeric IPv4, but forcibly treats all fields as decimal contrary to the RFC and POSIX. Hilarity ensues.
@dalias @bagder nss providers are just "files dns" as per defaults, but resolv.conf points to localhost. systemd-resolved synthesised an A record (*and* an NXDOMAIN) for 018.0.0.0 for some ungodly reason, but only on the first attempt. subsequent attempts seemed to have cached the NXDOMAIN. this is wildly broken
@astraleureka @dalias when the first number is a "bad octal", they all become decimal?
@astraleureka @dalias @bagder I really need to get back to working on shibari-cache, but WHEN goddammit