Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Proposed Renewal of the Registry Agreement for .NET (icann.org)
58 points by thesuperbigfrog on April 20, 2023 | hide | past | favorite | 38 comments


This is about the .net TLD and has nothing to do with .NET the framework.

It doesn't take long to realize this, it's even outright obvious considering ICANN is involved, but still... It seems weird to me that they would write .NET and .COM rather than .net and .com even if DNS is case-insensitive.


Using all caps goes back to the very first RFCs, so they probably stick to that for historical reasons even if the modern convention is lowercase.

https://datatracker.ietf.org/doc/html/rfc920#page-2


NO, HERE IS THE REASON WHY:

- THE INTERNET STARTED IN THE 1960'S.

- THE FIRST VIDEO DISPLAY TERMINALS THAT CAME OUT IN THE 70'S DIDN'T SUPPORT LOWERCASE, E.G. THE DEC VT05.

- PHYSICAL TELETYPES AT THE TIME ALSO WEREN'T GUARANTEED TO SUPPORT LOWERCASE, LIKE THE DECWRITER LA05.


Fun trick (I don't know if it still works): on the login prompt of your Linux (or other Unix) machine, type your username in all caps. This sets some strange termios(3) modes, which convert all lowercase output to UPPERCASE and all UPPERCASE input to lowercase. These modes are, AFAIK, for compatibility with these uppercase-only terminals.


Just tried it. Didn’t work.

(I tried it on a regular Linux virtual terminal (as is my normal way—I don’t use a graphical login manager), with my password in correct/inverted/upper/lower case, none work. It’s conceivable a pam module could make it work or something like that. I’m not investigating.)


Is your distribution still using getty?


Arch Linux with no meaningful configuration changes in this area. I understand so.


It's possible they disabled the switch in getty that enables the uppercase detection, it's -U....


You got any more info on that? I can't find anything online that talks about this trick



good luck with multi-case passwords...


Wait. You guys use passwords on your computers??


Fun fact: the earliest versions of the ASCII standard only had encodings for uppercase letters. (https://en.wikipedia.org/wiki/ASCII#History)


FORTRAN, COBOL and BASIC all used all caps in the 70s when I started to learn programming. People thought I was a nutcase for abandoning cursive in high school!

And don't get me started on punch card programming in college in 1980 :)


Despite ~60 years of updates, the fortran language still isn't case sensitive.


Why were people still using punchcards in the 80s?


Alas, at Princeton University 1980 that was the only way to submit programs. I was doing tech support for professors as part of my work-study package and a couple hours a week on a green-bar paper teletype sorta like this was a huge benefit: https://www.howtogeek.com/wp-content/uploads/2021/05/teletyp...


To make confetti out of the chads for parades. ;)


Huh? In 70s? But first version of Unix in C was written in lowercase.


I think in the past, internet signals were much weaker so EVERYONE HAD TO YELL to get their message through. Either that or 1-bits were in short supply.


After over 20 years of ambiguity, I don't think I'd honestly have the energy to worry about this if I were the person at ICANN deciding the headlines; it could have easily been avoided had the .NET framework just picked a less confusing name.


Additions in section 2.14 of the changes / redline document (https://itp.cdn.icann.org/en/files/registry-agreement/redlin...) are concerning:

"Registrar further acknowledges and agrees that Verisign reserves the right to deny, cancel, redirect or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, as it deems necessary, in its unlimited and sole discretion, for the purposes set forth in Section 2.7(b)(ii) of this Agreement."


Below are the purposes in 2.7(b)(ii). Note that the prior agreement already included purposes 1-3, but 4-6 are new.

> (1) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs),

> (2) to correct mistakes made by Verisign or any Registrar in connection with a domain name registration, or

> (3) for the non-payment of fees to Verisign; and,

> (4) to protect against imminent and substantial threats to the security and stability of the Registry TLD, System, Verisign’s nameserver operations or the internet,

> (5) to ensure compliance with applicable law, government rules or regulations, or pursuant to any legal order or subpoena of any government, administrative or governmental authority, or court of competent jurisdiction, and/or

> (6) to stop or prevent any violations of any terms and conditions of this Agreement, the Operational Requirements, or pursuant to Verisign’s Registry Agreement with ICANN;


> (1) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs),

This clause is probably the original motivation for this subsection (with 4, 5, and 6 being "obvious" corollaries of it): the .net TLD is the (de-facto?) place where Autonomous Systems expect to be able to register conventionally-named zones (format AS\d+\.NET), under which they then often register DNS names for things like backbone Internet switches.

Insofar as these ASes might be binding control-plane components to network middleboxes through these DNS names (unlikely, given the layer of the stack they operate on, but you never know), a takeover of their AS\d+\.NET domain-name would enable a wide-ranging attack on Internet infrastructure.

Additionally — though much less likely — you might be able to do some nefarious things just by squatting on an AS\d+\.NET domain name. If some engineer at the NOC is new there, and worked for other AS NOCs who did use AS\d+\.NET domain names to home equipment, but their new job doesn't, but they don't know that yet, they might misconfigure a system in a way that'd be innocuous if the domain was unregistered, but very bad if it was registered to an attacker.


I wonder why on earth this wasn't done properly by reserving, say, as.arpa. or at least using your AS number beneath a (properly registered) asn.net?


What you're imagining the function of the hypothetical "asn.net" to be, was just the intended function of the "net" TLD as a whole: it was a namespace for registering computer networks under, to give those networks' devices authoritative FQDNs in PTR records, and to give services like WHOIS something to point to to talk about "the operator of network X."

This intention included distinct Autonomous Systems, yes; but also ISP networks (which usually exist across many ASes to do their work).

Even today, if you do a PTR lookup on your own residential IP address, it probably resolves to a .net-suffixed FQDN.

I'm not sure when exactly Verisign (registrar operator of the .net TLD for its entire lifetime so far) went off the rails and began allowing usages outside the scope of "the management of computer networks." Almost certainly wasn't until a few years after the birth of the web (when everything having a marketable domain name became hip.) .net was definitely viewed as a "special" TLD, with special registration requirements, for a good long while — up through to at least the '90s, and possibly into the early '00s.

Honestly, I think it might just be a scalability-of-verification issue. Verisign might be able to check that every registrant in the US is a network operator (as was effectively all they had to do in the '80s); but every registrant in the entire world? A bit much to ask.

Which leads me to my current belief about why the network rules of .net as a TLD are currently the way they are: it's the least-work option for Verisign to keep the TLD going for its intended purpose. Rather than needing to individually verify every zone as a network, per the current rules, Verisign only needs to step in if a problem arises, or if there's a dispute between usages.

When such a thing happens, Verisign then does the "verification as being used for the operation of a computer network" step it theoretically should have been doing anyway; and if the domain fails the verification, Verisign takes it away.

---

That's for the DNS homing part. What about the "having an abuse website to complain to" part?

Well, in practice, AS network operators just don't care all that much about Internet principles of self-hosting, federation, public goods, etc. where their human-readable information is concerned.

Because of this, most ASes who own AS\d+\.NET zones don't actually maintain websites on them; and in fact don't maintain public websites anywhere. Instead — just like individuals hooked on Facebook — they rely on updating their human-readable metadata in public databases owned by private companies.

For every website like http://as9009.net/, there are ten ASes that would just tell you to go look at https://www.peeringdb.com/asn/9009.


It just feels crap that if I register as123125125.net then it might be taken off me just because a bunch of network operators can't be bothered to use the DNS properly.

You're quite right about the original intended purpose of .net, but even so if someone wants as125125.net they should register it properly not just be able to phone their mates at Verisign and get it taken away from someone who has paid for it.


Hmm these don't seem too nefarious to me...

4) probably don't need to worry about this unless you're using a .net domain to control your botnet

5) is this a practical change? If a court or government told them to take a domain down before they would have done so anyway right?

6) as a customer, it's not good idea to violate your contract with a service provider anyway right?


Is this a requirement from the US government for Verisign?


This makes sense since they are leasing domain names to you and not selling them to you.

You don’t own your Domain on the ICANN internet - and yes, that sucks.


>> You don’t own your Domain on the ICANN internet - and yes, that sucks.

True, but how should disputes be resolved?

Under this proposed change, if Verisign decides to cancel the lease for your .net domain, what can you do about it?


I don't think this change allows them to cancel your domain except for the purposes listed in sec. 2.7(b)(ii).


Is there an alternative? Just because you "bought" a domain gives you the right to use it to, say, co-ordinate a botnet that attacks other Internet systems?


Section 2.7b states:

"Registrar’s registration agreement with each Registered Name Holder, shall also include the following:

(i) a provision prohibiting the Registered Name Holder from distributing malware, abusively operating botnets, phishing, pharming, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law and providing (consistent with applicable law and any related procedures) consequences for such activities, including suspension of the registration of the Registered Name

(ii) a provision that requires the Registered Name Holder to acknowledge and agree that Verisign reserves the right to deny, cancel, redirect or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, as it deems necessary, in its unlimited and sole discretion:

(1) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs),

(2) to correct mistakes made by Verisign or any Registrar in connection with a domain name registration,

(3) for the non-payment of fees to Verisign;

(4) to protect against imminent and substantial threats to the security and stability of the Registry TLD, System, Verisign’s nameserver operations or the internet,

(5) to ensure compliance with applicable law, government rules or regulations, or pursuant to any legal order or subpoena of any government, administrative or governmental authority, or court of competent jurisdiction, and/or

(6) to stop or prevent any violations of any terms and conditions of this Agreement, the Operational Requirements, or pursuant to Verisign’s Registry Agreement with ICANN; and

(iii) a provision requiring the Registered Name Holder to indemnify, defend and hold harmless Verisign and its subcontractors, and its and their directors, officers, employees, agents, and affiliates from and against any and all claims, damages, liabilities, costs and expenses, including reasonable legal fees and expenses arising out of or relating to, for any reason whatsoever, the Registered Name Holder's domain name registration. The registration agreement shall further require that this indemnification obligation survive the termination or expiration of the registration agreement."

So basically Verisign has full authority to do whatever it wants regarding .net TLD domain names in order to prevent crimes and bad behavior, comply with laws, correct errors (who defines what is an error), and collect fees.

Many people are upset with these proposed changes because there are no recourse procedures outlined for domain holders.

If you hold a .net domain which you paid for and have been using for years and they decide that you are doing something they do not like or someone else claims ownership rights for your domain and convinces Verisign that they should have it, your domain can be forcibly transferred from you.

If you disagree with what they do, too bad.


Do you know why?


https://news.ycombinator.com/item?id=35638247

Yes concerning given the analysis at the site linked to the discussion. [1]

[1] https://freespeech.com/2023/04/19/red-alert-icann-and-verisi...


Arh, ICANN and VeriSign. Both have deliberately stalled on .Web


I found the explanation of the various domain names the best: https://www.name.com/domains/net

If you want to check any other domain name, just substitute the "net" with your own name. https://www.name.com/domains/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: