Re: Question about DNS naming conventions
Please tell the guy whose website says "Internet security & antispam” to fix HTTPS/TLS on his site: * Host enemieslist.com:443 was resolved. * IPv6: (none) * IPv4: 45.33.12.228 * Trying 45.33.12.228:443... * Connected to enemieslist.com (45.33.12.228) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version * Closing connection curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version On a lighter note, my favorite custom DNS PTRs are found on the route to bad.horse: https://pastebin.com/raw/4GSUHRy6 9 bad.horse (162.252.205.130) 171.987 ms 171.961 ms 172.387 ms 10 bad.horse (162.252.205.131) 177.009 ms 176.570 ms 177.807 ms 11 bad.horse (162.252.205.132) 182.312 ms 181.682 ms 181.581 ms 12 bad.horse (162.252.205.133) 186.254 ms 186.723 ms 186.896 ms 13 he.rides.across.the.nation (162.252.205.134) 191.581 ms 191.995 ms 192.539 ms 14 the.thoroughbred.of.sin (162.252.205.135) 196.768 ms 196.683 ms 197.056 ms 15 he.got.the.application (162.252.205.136) 201.184 ms 201.550 ms 201.829 ms 16 that.you.just.sent.in (162.252.205.137) 226.084 ms 206.611 ms 209.440 ms 17 it.needs.evaluation (162.252.205.138) 214.950 ms 211.952 ms 212.041 ms 18 so.let.the.games.begin (162.252.205.139) 216.997 ms 216.730 ms 217.574 ms 19 a.heinous.crime (162.252.205.140) 222.739 ms 313.316 ms 221.550 ms 20 a.show.of.force (162.252.205.141) 227.455 ms 226.936 ms 227.003 ms 21 a.murder.would.be.nice.of.course (162.252.205.142) 232.136 mse 232.144 ms 231.795 ms ie22 bad.horse (162.252.205.143) 237.418 ms 320.457 ms^U 237.265 ms 23 bad.horse (162.252.205.144) 282.589 ms 241.483 ms 299.596 ms 24 bad.horse (162.252.205.145) 313.476 ms 246.855 ms 292.823 ms 25 he-s.bad (162.252.205.146) 313.384 ms 277.220 ms 345.561 ms 26 the.evil.league.of.evil (162.252.205.147) 327.858 ms 256.816 ms 279.833 ms 27 is.watching.so.beware (162.252.205.148) 313.327 ms 261.990 ms 287.819 ms 28 the.grade.that.you.receive (162.252.205.149) 267.278 ms 267.262 ms 267.032 ms 29 will.be.your.last.we.swear (162.252.205.150) 352.531 ms 304.294 ms 271.968 ms 30 so.make.the.bad.horse.gleeful (162.252.205.151) 282.465 ms 278.175 ms 276.852 ms 31 or.he-ll.make.you.his.mare (162.252.205.152) 297.755 ms 281.298 ms 282.081 ms 32 o_o (162.252.205.153) 288.199 ms 286.632 ms 286.601 ms 33 you-re.saddled.up (162.252.205.154) 389.436 ms 327.868 ms 296.183 ms 34 there-s.no.recourse (162.252.205.155) 333.364 ms 328.371 ms 300.595 ms 35 it-s.hi-ho.silver (162.252.205.156) 326.765 ms 327.759 ms 313.318 ms 36 signed.bad.horse (162.252.205.157) 311.141 ms 330.010 ms 419.000 ms -T
On Feb 12, 2025, at 07:00, nanog-request@nanog.org wrote:
Message: 6 Date: 11 Feb 2025 20:30:47 -0500 From: "John Levine" <johnl@iecc.com> To: nanog@nanog.org Subject: Re: Question about DNS naming conventions Message-ID: <20250212013047.B06A6BC2C5F9@ary.qy> Content-Type: text/plain; charset=utf-8
Right. The names are usually created with BIND's $GENERATE extension or the equivalent in other DNS software.
There is a great deal of variation in the details of the names beyond the fact that they embed all or part of the IP address. I know a guy who has collected a lot of regular expressions to match them. See http://enemieslist.com
R's, John
On Wed, Feb 12, 2025 at 5:29 AM nanog--- via NANOG <nanog@nanog.org> wrote:
Please tell the guy whose website says "Internet security & antispam” to fix HTTPS/TLS on his site:
On Feb 12, 2025, at 07:00, nanog-request@nanog.org wrote: See http://enemieslist.com
You were told to use http. It's your own fault for escalating to https with no representation that a working https site was available at that URL. And then of course there's the completely fair question of whether it's sensible to forcibly deprecate older security protocols when accessing information that's also offered over fully unencrypted channels. Confidentiality, Integrity AND Availability. Lotta wounds to availability from forced deprecation. Whole lot. Also, as long as we're pointing out faults in others' behavior: top posting and hiding the poster's identity, both violations of the use conventions on this list. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On 2/12/2025 8:15 AM, William Herrin wrote:
And then of course there's the completely fair question of whether it's sensible to forcibly deprecate older security protocols when accessing information that's also offered over fully unencrypted channels. Confidentiality, Integrity AND Availability. Lotta wounds to availability from forced deprecation. Whole lot.
The software has no concept of what the data is and must provide the user the desired confidentiality and integrity, which unfortunately means forced deprecation and possible lack of Availability. This also applies to features such as HTTPS RRs in DNS that aren't always configured correctly and ECH prohibits fallback when it breaks; choosing security over availability. I do wish browsers were better at explaining why something breaks, though. It's especially bad with embedded content where it just doesn't work and even dev tools might show "server disconnected prematurely" or something similar. Jack
On Wed, Feb 12, 2025 at 9:58 AM Jack Bates <jbates@paradoxnetworks.net> wrote:
The software has no concept of what the data is
Which is why the software shouldn't be making a hard decision about appropriate cryptography. The users on the two ends, the folks who do know what the data is, should have the final say. The software should set sensible defaults and then let those users decide what to do about the large and growing gap of failure between the current default and the often still allowed unencrypted plain text. That "curl https://enemieslist.com" returns a fault is not unreasonable. That "curl --insecure https://enemieslist.com" also fails reflects faulty thinking on the part of alleged security experts. My personal pain point is out of band access to older servers. They're well past the manufacturer's maintenance so there are no more software updates. I can use nice modern VPN software to secure the channel between me and their LAN, but I have to maintain obsolete versions of web browsers and their dependent libraries along with obsolete versions of Java because the modern ones won't connect. I'd rather have less obsolete bug ridden software around, but the self-appointed security experts have stolen that choice from me. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
The software has no concept of what the data is Which is why the software shouldn't be making a hard decision about appropriate cryptography. The users on the two ends, the folks who do know what the data is, should have the final say. The software should set sensible defaults and then let those users decide what to do about
On Wed, Feb 12, 2025 at 9:58 AM Jack Bates <jbates@paradoxnetworks.net> wrote: the large and growing gap of failure between the current default and the often still allowed unencrypted plain text. Most users don't have any idea and would allow an attacker to compromise
On 2/12/2025 2:34 PM, William Herrin wrote: their bank connection if given the choice. The defaults are designed to protect the majority?
That "curl https://enemieslist.com" returns a fault is not unreasonable. That "curl --insecure https://enemieslist.com" also fails reflects faulty thinking on the part of alleged security experts. I suspect --insecure has special meaning and shouldn't be overloaded to include anything that is "insecure". However, curl depends on the underlying libraries, and I believe it was those libraries that are being compiled and installed with older stuff disabled. A quick search shows you have to do custom builds to enable on any current system.
My personal pain point is out of band access to older servers. They're well past the manufacturer's maintenance so there are no more software updates. I can use nice modern VPN software to secure the channel between me and their LAN, but I have to maintain obsolete versions of web browsers and their dependent libraries along with obsolete versions of Java because the modern ones won't connect. I'd rather have less obsolete bug ridden software around, but the self-appointed security experts have stolen that choice from me.
In my experience, except for Java incompatibilities itself, you can usually tweak the configuration and exception rules to get Java to connect and accept older signed packages. Sometimes you have to retweak after an upgrade. FireFox appears to have quite a few options in about:config to enable older stuff and also supports exception lists for some things. Of course, my experience is limited, and I may not be nearly as archaic as you. Jack
On Wed, Feb 12, 2025 at 7:53 PM Jack Bates <jbates@paradoxnetworks.net> wrote:
Most users don't have any idea and would allow an attacker to compromise their bank connection if given the choice. The defaults are designed to protect the majority?
I see no issue with the server user deciding that it won't converse with a client user beneath some level of cryptographic quality. The server operator has a reasonable idea how sensitive his information is. My bank shouldn't agree to talk to me with TLSv1.0. Same with the client user. He has a reasonable idea how much care he wants the data to be given. My qualm arises when a third party without any knowledge of the data denies one of the users the ability to meet the other at the other's lower cryptographic standard. This is damage to availability in a situation where a meaningful gain to confidentiality or integrity has not been demonstrated and may be demonstrably false. Such as the situations described upthread. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
on Wed, Feb 12, 2025 at 08:29:30AM -0500, nanog--- via NANOG wrote:
Please tell the guy whose website says "Internet security & antispam” to fix HTTPS/TLS on his site:
My bad, I dropped support for SSL while waiting for a certificate upgrade and forgot to remove the ssl.conf from sites-enabled while I was waiting; it isn't really a top priority given that the site only has a few pages, but it's back on the list of things to fix one of these days. I'd thank you in person and offlist, but... -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ Internet security and antispam hostname intelligence: http://enemieslist.com/
participants (4)
-
Jack Bates -
nanog＠fleish.org -
Steven Champeon -
William Herrin