-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2023-03-08 at 14:04 -0800, Marc Chamberlin wrote:
Hello - I am running an OpenSuSE 15.3 x64 system where I am also running a NAMED server for my network.
quasar:/etc/named.d # named -v BIND 9.16.6 (Stable Release) <id:25846cf> quasar:/etc/named.d # ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 Apparently recently something has changed which is now breaking SSH's ability to connect to a URL with upper case letters in the host name. (I connect and use SSH within a port knocking script which has worked for many years, so I know it is not caused by something I am doing, but by a change that has occurred within either SSH or NAMED.) Internet and Googling searches seem to imply that Bind (NAMED) is now resolving URL's in a case sensitive fashion. https://kb.isc.org/docs/aa-01113 and I suspect this change has just now caught up with me.
My machine Isengard was updated from 15.2 to 15.3 this week, and within hours to 15.4, and is running named, so I'll test. I also use some times upper case names, since ever. I don't remember configuring for this. cer@Telcontar:~/Download/Firefox_downloads> ssh cer@isengard.valinor Last login: Mon Mar 6 03:52:27 2023 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> logout Connection to isengard.valinor closed. cer@Telcontar:~/Download/Firefox_downloads> ssh cer@Isengard.Valinor Last login: Thu Mar 9 11:18:26 2023 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> named -v Absolute path to 'named' is '/usr/sbin/named', so running it may require superuser privileges (eg. root). cer@Isengard:~> /usr/sbin/named -v BIND 9.16.37 (Extended Support Version) <id:2b2afb2> cer@Isengard:~> ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1l 24 Aug 2021 SUSE release 150400.7.25.1 cer@Isengard:~> sshd -V Absolute path to 'sshd' is '/usr/sbin/sshd', so running it may require superuser privileges (eg. root). cer@Isengard:~> /usr/sbin/sshd -V unknown option -- V OpenSSH_8.4p1, OpenSSL 1.1.1l 24 Aug 2021 SUSE release 150400.7.25.1 usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file] [-E log_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-o option] [-p port] [-u len] cer@Isengard:~> cer@Isengard:~> ssh cer@telcontar.valinor Password: Last login: Mon Jan 30 14:18:41 2023 Have a lot of fun... If you wish women to love you, be original; I know a man who wore fur boots summer and winter, and women fell in love with him. -- Anton Chekhov cer@Telcontar:~> logout Connection to telcontar.valinor closed. cer@Isengard:~> ssh cer@Telcontar.Valinor Password: Last login: Thu Mar 9 11:19:31 2023 from 192.168.1.16 Have a lot of fun... Laugh, and the world ignores you. Crying doesn't help either. cer@Telcontar:~> logout Connection to telcontar.valinor closed. cer@Isengard:~> logout Connection to isengard.valinor closed. cer@Telcontar:~/Download/Firefox_downloads>
But, I don't know if the fault lies entirely with Bind/NAMED. SSH appears to be mangling URLs, changing upper case letters within a URL, to lower case before asking a name server to resolve them. (IMHO this is extremely bad behavior on SSH's part because it is destroying user supplied data, something a program should never do!) Here is an example of what I am seeing that leads me to this conclusion -
ssh marc@darkstarINT.mydomain.com ssh: connect to host darkstarint.mydomain.com port 22: No route to host
cer@Telcontar:~/Download/Firefox_downloads> ssh cer@Isengard.Valinor Last login: Thu Mar 9 11:27:12 2023 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> ssh marc@darkstarINT.mydomain.com ssh: Could not resolve hostname darkstarint.mydomain.com: Name or service not known cer@Isengard:~>
Notice SSH changed the upper case "INT" in the host name "darkstarINT" to a lower case "int" in the query. I checked the log file at /var/log/named/named and indeed saw the query for the URL, from SSH, was all lower case. The message "No route to host" is misleading (probably because of bad error handling) and just means SSH was unable to get an IP address from the DNS server for the URL host name, that it mangled.
Well, AFAIK that all software that don't differentiate for case do the same. They either convert to upper case or lowercase as part of the process. I believe that the library functions that compare strings without caring for case do the same thing, convert both strings to upper case before comparing.
Doing some further Googling, I found some references to using an ACL declaration in the NAMED configuration files, but I am unable to find any easy/clear guidance or examples on how to do this.
Isengard:~ # grep -i ACL /etc/named.conf Isengard:~ # grep -i ACL /etc/named.d/* Isengard:~ #
Does anyone here know either how to keep SSH from converting a URL, that it is querying, to stop this horrid conversion of a URL to all lower case, or how to get NAMED to handle queries in a case insensitive manner? (perhaps using the ACL declaration that I found some references to.) If not, does anyone know of a better forum I could ask? Links to documentation, with examples, would also be appreciated, after hours of searching I was not able to find anything helpful.
I know I could go through all my NAMED configuration files and and either add duplicate zones or use CNAME perhaps to add in all lower case equivalent host names but that seems like a huge burden and a bunch of extra maintenance overhead.
Isengard:/var/lib/named # grep -i legolas valinor.zone Legolas A 192.168.1.126 MX 10 Legolas Legolas-e A 192.168.1.127 MX 10 Legolas Isengard:/var/lib/named # host lEgolas Legolas.valinor has address 192.168.1.126 Legolas.valinor mail is handled by 10 Legolas.valinor. Isengard:/var/lib/named #
Thanks and as always appreciate thoughts, ideas, and the time it takes to write a reply... Marc...
Welcome :-) - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZAm42Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV9YwAn0J8LyNKuooIg8gwQO11 KoQdj77bAJ9PhXAa/eiJ65u8TH6x2SRAT212Sw== =kq2s -----END PGP SIGNATURE-----