Cool, thanks. We had a couple of other reports of people making support calls and being asked to reboot their modems, so I wanted to make sure tier 3 had gotten it. And I figured tier 3 would be here. :-) Cheers, -- jra On July 4, 2024 3:00:12 PM EDT, Ryan Hamel <ryan@rkhtech.org> wrote:

I called their support when that outage thread came in, they're already aware and taking a look now.

Ryan Hamel

________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Jay Ashworth <jra@baylink.com> Sent: Thursday, July 4, 2024 11:55 AM To: nanog@nanog.org <nanog@nanog.org> Subject: HE.net problem

Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.

We have a report on outages that he.net has been placed in ICANN client hold, and people's DNS service is falling over on this Independence day. If you work in DNS for HE, you might want to look into this.

I have double checked the report, and I am seeing the status as well.

Hurricane serves lots of dns, I would classify this as a P1 ticket.

Cheers, -- jra -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Mel, Your local caching resolver knows the IPs for ns[1-5].he.net, which skips over the need for querying the root DNS resolvers, and gtld-servers (glue records). If the TTL (2 days) expires on your resolver before HE fixes their issue, you will not be able to resolve anything for that domain. At the moment, a simple DNS trace (dig he.net +trace) cannot complete fully. Ryan Hamel ________________________________ From: Mel Beckman <mel@beckman.org> Sent: Thursday, July 4, 2024 12:20 PM To: Jay Ashworth <jra@baylink.com> Cc: Ryan Hamel <ryan@rkhtech.org>; nanog@nanog.org <nanog@nanog.org> Subject: Re: HE.net problem Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Our he.net dns appears to be fine at this time: $ nslookup server ns1.he.net Default server: ns1.he.net Address: 2001:470:100::2#53 Default server: ns1.he.net Address: 216.218.130.2#53

set type=A jet.net. Server: ns1.he.net Address: 216.218.130.2#53

Name: jet.net Address: 206.83.0.42 -mel beckman On Jul 4, 2024, at 12:11 PM, Jay Ashworth <jra@baylink.com> wrote:  Cool, thanks. We had a couple of other reports of people making support calls and being asked to reboot their modems, so I wanted to make sure tier 3 had gotten it. And I figured tier 3 would be here. :-) Cheers, -- jra On July 4, 2024 3:00:12 PM EDT, Ryan Hamel <ryan@rkhtech.org> wrote: I called their support when that outage thread came in, they're already aware and taking a look now. Ryan Hamel ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Jay Ashworth <jra@baylink.com> Sent: Thursday, July 4, 2024 11:55 AM To: nanog@nanog.org <nanog@nanog.org> Subject: HE.net problem Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. We have a report on outages that he.net has been placed in ICANN client hold, and people's DNS service is falling over on this Independence day. If you work in DNS for HE, you might want to look into this. I have double checked the report, and I am seeing the status as well. Hurricane serves lots of dns, I would classify this as a P1 ticket. Cheers, -- jra -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Aha. Just as I suspected, bureaucrats at Network Solutions are to blame. I have had many run-ins with NS and their inscrutable policies and odd viewpoints. I was once suspended for running a web cache that NS incorrectly claimed was stealing domain content. No engineer on the NS side seemed to know what a web cache does. -mel via cell On Jul 4, 2024, at 12:42 PM, Mel Beckman <mel@beckman.org> wrote:  Ryan, Right you are. The dig still fails. hopefully the ICANN issue gets fixed, and a pox on any bureaucrat who arranged for this to happen over a holiday weekend! -mel On Jul 4, 2024, at 12:33 PM, Ryan Hamel <ryan@rkhtech.org> wrote:  Mel, Your local caching resolver knows the IPs for ns[1-5].he.net, which skips over the need for querying the root DNS resolvers, and gtld-servers (glue records). If the TTL (2 days) expires on your resolver before HE fixes their issue, you will not be able to resolve anything for that domain. At the moment, a simple DNS trace (dig he.net +trace) cannot complete fully. Ryan Hamel ________________________________ From: Mel Beckman <mel@beckman.org> Sent: Thursday, July 4, 2024 12:20 PM To: Jay Ashworth <jra@baylink.com> Cc: Ryan Hamel <ryan@rkhtech.org>; nanog@nanog.org <nanog@nanog.org> Subject: Re: HE.net problem Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. Our he.net dns appears to be fine at this time: $ nslookup server ns1.he.net Default server: ns1.he.net Address: 2001:470:100::2#53 Default server: ns1.he.net Address: 216.218.130.2#53

set type=A jet.net. Server: ns1.he.net Address: 216.218.130.2#53

Name: jet.net Address: 206.83.0.42 -mel beckman On Jul 4, 2024, at 12:11 PM, Jay Ashworth <jra@baylink.com> wrote:  Cool, thanks. We had a couple of other reports of people making support calls and being asked to reboot their modems, so I wanted to make sure tier 3 had gotten it. And I figured tier 3 would be here. :-) Cheers, -- jra On July 4, 2024 3:00:12 PM EDT, Ryan Hamel <ryan@rkhtech.org> wrote: I called their support when that outage thread came in, they're already aware and taking a look now. Ryan Hamel ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Jay Ashworth <jra@baylink.com> Sent: Thursday, July 4, 2024 11:55 AM To: nanog@nanog.org <nanog@nanog.org> Subject: HE.net problem Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. We have a report on outages that he.net has been placed in ICANN client hold, and people's DNS service is falling over on this Independence day. If you work in DNS for HE, you might want to look into this. I have double checked the report, and I am seeing the status as well. Hurricane serves lots of dns, I would classify this as a P1 ticket. Cheers, -- jra -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Yup; I blew that one too. I've been told it was cleared around 2020Z, and whois reflects that, though my dig +trace doesn't seem to be behaving as expected. Cheers, -- jra ----- Original Message -----

From: "Crist Clark" <cjc+nanog@pumpky.net> To: "Mel Beckman" <mel@beckman.org> Cc: nanog@nanog.org Sent: Thursday, July 4, 2024 4:52:14 PM Subject: Re: HE.net problem

On the other side of this, we all may be learning the value of not having all of you NS records in a single zone with a domain under a single registrar.

(From someone who has personal domains hosted on HE DNS.)

On Thu, Jul 4, 2024 at 1:01 PM Mel Beckman <mel@beckman.org> wrote:

...

Aha. Just as I suspected, bureaucrats at Network Solutions are to blame. I have had many run-ins with NS and their inscrutable policies and odd viewpoints. I was once suspended for running a web cache that NS incorrectly claimed was stealing domain content. No engineer on the NS side seemed to know what a web cache does.

-mel via cell

On Jul 4, 2024, at 12:42 PM, Mel Beckman <mel@beckman.org> wrote:

 Ryan,

Right you are. The dig still fails. hopefully the ICANN issue gets fixed, and a pox on any bureaucrat who arranged for this to happen over a holiday weekend!

-mel

On Jul 4, 2024, at 12:33 PM, Ryan Hamel <ryan@rkhtech.org> wrote:

 Mel,

Your local caching resolver knows the IPs for ns[1-5].he.net, which skips over the need for querying the root DNS resolvers, and gtld-servers (glue records). If the TTL (2 days) expires on your resolver before HE fixes their issue, you will not be able to resolve anything for that domain.

At the moment, a simple DNS trace (dig he.net +trace) cannot complete fully.

Ryan Hamel

------------------------------ *From:* Mel Beckman <mel@beckman.org> *Sent:* Thursday, July 4, 2024 12:20 PM *To:* Jay Ashworth <jra@baylink.com> *Cc:* Ryan Hamel <ryan@rkhtech.org>; nanog@nanog.org <nanog@nanog.org> *Subject:* Re: HE.net problem

Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.

Our he.net dns appears to be fine at this time:

$ nslookup server ns1.he.net Default server: ns1.he.net Address: 2001:470:100::2#53 Default server: ns1.he.net Address: 216.218.130.2#53

...

set type=A jet.net. Server: ns1.he.net Address: 216.218.130.2#53

Name: jet.net Address: 206.83.0.42

-mel beckman

On Jul 4, 2024, at 12:11 PM, Jay Ashworth <jra@baylink.com> wrote:

 Cool, thanks. We had a couple of other reports of people making support calls and being asked to reboot their modems, so I wanted to make sure tier 3 had gotten it.

And I figured tier 3 would be here. :-)

Cheers, -- jra

On July 4, 2024 3:00:12 PM EDT, Ryan Hamel <ryan@rkhtech.org> wrote:

I called their support when that outage thread came in, they're already aware and taking a look now.

Ryan Hamel

------------------------------ *From:* NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Jay Ashworth <jra@baylink.com> *Sent:* Thursday, July 4, 2024 11:55 AM *To:* nanog@nanog.org <nanog@nanog.org> *Subject:* HE.net problem

Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.

We have a report on outages that he.net has been placed in ICANN client hold, and people's DNS service is falling over on this Independence day. If you work in DNS for HE, you might want to look into this.

I have double checked the report, and I am seeing the status as well.

Hurricane serves lots of dns, I would classify this as a P1 ticket.

Cheers, -- jra

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

not to distract from everyone diagnosing someone else's problem, but ... what foss dns monitoring tools do folk use to alert of - iminent delegation expiry - inconsistent service (lame, soa mismatches, ...) - dnssec signing and timer issues - etc. randy

...

what foss dns monitoring tools do folk use to alert of - iminent delegation expiry - inconsistent service (lame, soa mismatches, ...) - dnssec signing and timer issues - etc. https://github.com/berthubert/simplomon

thanks. may play hak whacked me to add http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_exp... to my nagios deployment. anyone have some known sick in various ways dns zones against which to test? randy

On 4 Jul 2024, at 23:22, Paul Ebersman <list-nanog2@dragon.net> wrote:

cjc> On the other side of this, we all may be learning the value of not cjc> having all of you NS records in a single zone with a domain under a cjc> single registrar.

From some trainings I did on how to be sure your DNS was robust:

- don't have all your business critical domains under the same registrar (unless it's of the CSC/markmonitor class)

Please note that: - Markmonitor is owned by Newfold Digital / Endurance International [1] - Network Solutions is owned by Web.com <http://web.com/> [2] - Web.com <http://web.com/> is... owned by Newfold Digital [3] But yes, if you pay MM, you likely get to keep your domain. Note that NetSol is also not the NetSol anymore from the 1990's that one got tshirts from when you got a domain. [1] https://en.wikipedia.org/wiki/Markmonitor [2] https://en.wikipedia.org/wiki/Network_Solutions [3] https://en.wikipedia.org/wiki/Endurance_International_Group And... we all still have ICANN as an ultimate power, and the TLD itself, next to the above registrar. There is always going to be single point of failures in a hierarchical tree like that.

- don't have all your auth NS for your domain in bailiwick (within the domain being served)

If, as it is the example in the thread, he.net <http://he.net/> is your primary domain, which is their case, then if somebody in the tree disables the delegation of he.net <http://he.net/>, nothing is going to fix resolution to you. Having your DNS servers in another TLD will not make he.net <http://he.net/> appear in the global DNS again... And if you look at multiple large sites, the google.com <http://google.com/> akamai.com of the world, their registrar is MM, DNS are in-bailiwick and in-AS. Indeed, for domains that are not 'infrastructure', where one uses out of bailiwick DNS servers, that can help, but also cause issues. But, if we have for instance: example.com <http://example.com/> NS ns1.example.net <http://ns1.example.net/> NS ns2.example.org <http://ns2.example.org/> NS ns3.example.com <http://ns3.example.com/> Then: - if .com decided to kick you out, you are out - if .net or .org decide to kick you out you lose 1/3rd of your queries and induce latency... (at which point one can still remove the glue, but that will be another hour before gone) Thus one only increases the risk by having multiple TLDs. Choosing a trusted registrar (one you have good contact with; indeed MM qualifies) and a TLD that will not cause you issues, is thus more important.

- don't have all your auth NS in the same routing domain (anycast can be an exception to this if robust enough)

Yep, that is a decent rule. But if you control your routing domain (AS, different prefixes), less external issues that can happen ;) Many of these rules btw are tested with https://www.zonemaster.net/ Though, one will see that many of the big sites do not have that; but they also use MM, and have 24/7 teams to fix things.

- don't have the account registrar credential emails all within the domain, nor with personal emails like gmail. do have them all under control of your IT

Accounts in different domains can be indeed a rather good one to think about, definitely for communication when the main domain is broken, at least the other domains are then on file for contacting. Hopefully those email addresses cannot be used for account recovery, as then one increases risk again.

- protect all account credentials with strong passwords, MFA - have MX for your domain either with a very large provider or across multiple domain names

It's painfully easy to fall off the internet and be unreachable if you're not thinking about all this for business critical domains. You don't ever want to be hoping that some customer kept your NOC phone number in their phone. ;)

Indeed; The weakest point is where the chain breaks... one can have a simple chain or a very distributed chain. Greets, Jeroen

It appears that Bill Woodcock <woody@pch.net> said:

ICANN’s going to open another round of TLD applications, and I expect a lot of companies to go into that with their eyes more open than last time, knowing why they’re doing it. It’s not about brand protection, it’s about disintermediating the root of trust and giving yourself a solid foundation for your security architecture.

I take your point, but I also observe ICANN's list of abandoned vanity TLDs which now has 134 entries, companies that paid the fee, went all the way through the application process, paid to get their TLD set up and signed and put in the root, probably costing them on the order of $500K in all. Then later they decided the TLDs are worthless and mailed the keys back to ICANN. Here's the 134 who have abandoned so far, with more every few months: https://www.icann.org/resources/pages/gtld-registry-agreement-termination-20... Also, getting your own TLD doesn't necessarily make your risks less, it just makes them different. You now have a direct relationship with the registry back end provider that you have to not screw up, and due to ICANN's rules, there is a registrar between you and your registry for each of your names, e.g. payme.hsbc is registered through Comlaude. I do not see why this would be any better than a .COM registered through CSC.* I will be interested to see how the next round goes. As seen from anyone outside the ICANN bubble who can do simple arithmetic, the current round has been an utter failure for everyone other than ICANN and the people who sucked money out of the process (which includes me, but not so much I particularly want to do it again.) R's, John * - I have argued with CSC about updates to the IANA domains and found it is nearly impossible to get them to change anything even when you follow the process they set up. I would expect it to be even harder to get them to make changes outside of the process. Their whole business model is not to annoy their large company clients most of which also use them for Delaware corporate paperwork.

I've found this conversation hugely of interest… The below isn't really a question, more of a high level clarification/further thinking. First, what actually happened and the impact (correct me if any of this is wrong): A stupid phishing complaint to NetSol by a 3rd party got he.net put into client hold. As a result, assuming there is no cache protection, name servers around the world trying to lookup anything.he.net were failing because ROOT servers said go to NetSol for .net, and netsol had no answer for he.net due to client hold. This means: 1. he.net <http://he.net/> website would have been down regardless if their Auth NS was split Auth and split across TLDs 2. customer.com <http://customer.com/> website would be down is customer.com used NS1.HE.NET <http://ns1.he.net/> and NS2.HE.NET <http://ns2.he.net/> as Auth DNS because that resolution would fail due to he.net <http://he.net/> being clienthold at NetSol 2.a. customer.com <http://customer.com/> website would be UP if customer.com <http://customer.com/> used NS1.HE.NET <http://ns1.he.net/> and NS2.HE.ORG <http://ns1.he.org/> as Auth DNS… assuming HE implemented secondary NS servers on another TLD, or secondary was Cloudflare or something. Obviously the root cause was a glitch, but if it wasn’t a phishing report it could have been any other number of human errors, billing issue, internal NetSol glitch/fat fingering, etc.,. something requiring human intervention - which is hard to do these days because nobody has a 24x7 NOC with real people who can make real changes. #2 could have been protected by #2A, but as others have said #1 isn’t really possible to 100% protect against. Yes, HE could get and use their own vanity TLD at huge expense (say .he TLD) and since they control it a glitch like this cant burn them, but you just trade risk because now you have to maintain the infra of this TLD. So #1’s the easiest fix - just use MarkMonitor. Ok…. now a rabbit hole. I looked at some vanity TLDs, and it appears the ALOT of big companies have their names as TLDs, but almost none of them are using it for anything. Why is that? Is it just a copyright play to protect the name from some else taking it? Then it got me interested, assuming a company already has the infra, what is a realistic cost to get your own TLD and actually use it for yourself (and maybe others)? I saw something online that said $250,000 but that didn’t make sense if its all paperwork. Again, this assumes you already have infra to use. -John

On Jul 5, 2024, at 5:18 AM, Bill Woodcock <woody@pch.net> wrote:

...

On Jul 5, 2024, at 09:53, Jeroen Massar via NANOG <nanog@nanog.org> wrote: Please note that: - Markmonitor is owned by Newfold Digital / Endurance International [1] - Network Solutions is owned by Web.com <http://web.com/> [2] - Web.com <http://web.com/> is... owned by Newfold Digital [3]

And... we all still have ICANN as an ultimate power, and the TLD itself, next to the above registrar.

There is always going to be single point of failures in a hierarchical tree like that.

Taking off on what Jeroen is saying here… A huge amount of PCH’s work is with TLD registries. Much of that is ccTLDs, national domains, but a fair bit is also with brand TLDs. I think a lot of people are dismissive of brand TLDs, thinking “oh, that’s just trademark protection.” And MarkMonitor and CSC were, admittedly, a part of the reason why people treat them dismissively. The majority of brand TLDs lie fallow, with little to no use.

That’s unfortunate, because a TLD of its own is one of the VERY BEST things an organization can do to reduce security externalities. It’s a really foundational building-block in modern security. You can do DNSSEC and DANE and use all of the security tools and processes that build upon those, without having to depend upon the (largely non-existent) security of the registrar-registry chain. There are more protocols and tools coming down the pike that build further on that foundation. There are browsers coming which will trust the existence or non-existence of a DANE cert, without allowing a downgrade attack to a bogus CA cert. There are Digital Emblems coming (participate in the BoF at the IETF if you care!). That leaves you with just the one (?) externality of the IANA (and the RZM agreement) which, yeah, you’re not going to get past. But that’s done very, very securely, so if you have to trust one external party, at least they’re _competent_ and well-funded and not going to get acquired by a Florida Man private-equity outfit.

ICANN’s going to open another round of TLD applications, and I expect a lot of companies to go into that with their eyes more open than last time, knowing why they’re doing it. It’s not about brand protection, it’s about disintermediating the root of trust and giving yourself a solid foundation for your security architecture.

-Bill

essen> I saw something online that said $250,000 but that didn't make essen> sense if its all paperwork. woody> Heh. I see you are unfamiliar with ICANN. They've said that woody> same paperwork is likely to cost $375k in ICANN staff time for woody> the next round. Because, you know, inflation or something. And $250k was not really the cost last time either. By the time you did legal fees, deposits, fees, NOC, etc. it was closer to $500k per TLD. If there is similar inflation on all the extra costs, that probably means $600-700k next time. I've been surprised that none of the folks that got TLDs seem to be leveraging the technical/security brand protection like they could. If I have an LG TV and it wants to update to <mumble>.LG and LG is DNSSEC signing the whole chain, that sure seems more likely to be legit than <mumble>.lg.tv or some such. Add in that if you do brand, short of the root zone dumping you for some reason, you own your experience and your full resolution chain. You can pick who/how/where for all the labels, servers, anycast infra, etc. But I haven't seen a lot of interest in taking advantage of that added potential layer of security.

If you’re LG, you own the software, you do cert pinning. Also, realize many (most? almost all?) are going to outsource the management of their vanity TLD to one of the existing companies in that market. Think of a brand that sells, I don’t know, shoes. Running a TLD is not part of their core business. It makes no sense to do this in-house. So now it’s a contractual agreement with some third party again anyway. You depend on their help desk, their security, and all of the other vendors that they outsource other bits to. Heck, even hugest of huge IT companies out source this stuff. .apple backend is outsourced to Afalias. On Sat, Jul 6, 2024 at 2:02 PM Bill Woodcock <woody@pch.net> wrote:

...

On Jul 6, 2024, at 22:41, Paul Ebersman <list-nanog2@dragon.net> wrote: I've been surprised that none of the folks that got TLDs seem to be leveraging the technical/security brand protection like they could.

A few are. A very few. SNCF. A few banks.

...

If I have an LG TV and it wants to update to <mumble>.LG and LG is DNSSEC signing the whole chain, that sure seems more likely to be legit than <mumble>.lg.tv or some such.

Ayup. Particularly if they don’t allow downgrade attacks to CA certs.

I think there are a few more brands looking to make this move to higher security in the new ngTLD round. At least everybody’s a lot more educated this time around.

-Bill

If I have an LG TV and it wants to update to <mumble>.LG and LG is DNSSEC signing the whole chain, that sure seems more likely to be legit than <mumble>.lg.tv or some such.

.lg and .he were mentioned as possible brand TLDs, but those are not allowed, because they are reserved for possible ccTLDs. gTLDs are required to have at least 3 ASCII characters or 2 Unicode characters, with the 2026 round bringing the possibility of 1 Unicode character gTLDs in Han Script (mostly known as CJK - Chinese, Japanese, Korean for the most representative languages using that script). Rubens

FWIW I think TLDs should cost much more, like millions, other than where they provide legitimate internationalization or specific community service functions (TBD.) 1. They're just polluting the name space, many seem frivolous like .RODEO or .FISHING (yeah those are real.) 2. Vanity corporate TLDs should cost twice that or more. 3. One problem with frivolous is they don't sell many SLDs so either go under and have to be bailed out because, ya know, oh no the registrants! (see EBERO), or just limp along, some barely able to function as companies. A higher fee would be a higher bar. TLDs should NOT be priced on a cost plus basis so any reasoning like what could it cost to process a TLD app should be irrelevant. Also, due to name collisions, i.e., more than one applicant going after the same TLD, some of these actually did go for millions, often in private auctions. And some have yet to be resolved from the last round: I know of several which are yet to function. Who cares? Well, maybe some were worthwhile and maybe if they were much higher priced someone more capable would have obtained them rather than spend a decade dithering. Warning: This is an abbreviated version of my opinion on this but how much would you have sat still for? I've been to quite a few ICANN meetings, I'm not just spouting new, half-thought-out impressions. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On 07/07/2024, 01:06:59, "Robert McKay via NANOG" <nanog@nanog.org> wrote:

People aren't used to URLs not ending in .com or possibly their local ccTLD. Anything else looks suspicious or isn't even recognised as a URL and less people will visit it.

True but when you are multinational you probably have a .com plus a lot of country ones, even if they just redirect, to avoid local fakery. It gets quite messy protecting the brond and the more domains you have the easier it is to fool someone to accept another similar one. One definitive name can be help.

It doesn't even make your URL shorter because you'd need to include "www." in front to have any chance of it being recognised as a URL. Perhaps even "https://www." to drive home the point.

When I did ours I had a test site the.bbc up for a while until google started pushing traffic to it. It seemed a lot nicer to say on air than www.bbc.co.uk / .com, and nicely authoritative. I hope it will be used eventually. brandon

ebersman> - don't have all your business critical domains under the same ebersman> registrar (unless it's of the CSC/markmonitor class) jeroen> There is always going to be single point of failures in a jeroen> hierarchical tree like that. Everything in internet/infrastructure is risk tradeoffs and cost/benefit analysis. If we could be perfect as engineers, we would be. ;) Personally, the fact that the internet mostly functions most mornings when I get up is still something that amazes me after years of using it... ebersman> - don't have all your auth NS for your domain in bailiwick ebersman> (within the domain being served) jeroen> If, as it is the example in the thread, he.net <http://he.net/> jeroen> is your primary domain, which is their case, then if somebody in jeroen> the tree disables the delegation of he.net <http://he.net/>, jeroen> nothing is going to fix resolution to you. Having your DNS jeroen> servers in another TLD will not make he.net <http://he.net/> jeroen> appear in the global DNS again... The above two points of mine tie together. If you can afford a registrar who will be far more likely to care about you than random/bad enforcement of external complaints and you're big/rich enough to be able to use highly robust anycasted auth NS, in bailiwick is a much lower risk. If my "joe's fish shop and internet cafe" DNS is provided by "my mom let me be a registrar if I ate my vegetables" diversity of TLD, registrar, and auth NS (including out of bailiwick NS) becomes a much more attractive and cheaper way to be more robust. jeroen> Thus one only increases the risk by having multiple jeroen> TLDs. Choosing a trusted registrar (one you have good contact jeroen> with; indeed MM qualifies) and a TLD that will not cause you jeroen> issues, is thus more important. Again, this depends on scale. For SMB, multiple TLDs is more likely to be a feature, for a really large business not so much. As Bill points out, this is actually one of the few cases where brand TLD is a major potential security upgrade.

----- Original Message -----

From: "Robert L Mathews" <lists@tigertech.com>

However, if "example.com" uses "ns1.he.net" and "ns2.he.net" as its nameservers, having the second of those instead be "ns2.he.org" will keep "www.example.com" reachable if he.net is placed on clientHold.

That was presumably the emergency concern in this case -- not so much that www.he.net itself was offline, but that all the other domains using their nameservers were offline.

Correct. I was not the person who made the original query/report, but that was the concern which made me run the event up the flagpole here and on Outages.

I run a registrar so there's no risk of our domain names getting put on clientHold, but I still don't trust the *registry* not to put one of our domain names on their equivalent "serverHold".

And it is there that perhaps I overreacted one step; I had thought from the data I heard that that *was* a registry-side hold (and hence it didn't matter that it was NetSol). Or perhaps that NetSol was still the registry for .net -- that's out of date now, isn't it? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

See how little it has been necessary for me to pay attention to them since my net handle was assigned back in the early 90s or maybe late 80s? ;-) Cheers, -- jra3 On July 6, 2024 11:11:50 AM EDT, John Levine <johnl@iecc.com> wrote:

According to Jay R. Ashworth <jra@baylink.com>:

...

data I heard that that *was* a registry-side hold (and hence it didn't matter that it was NetSol). Or perhaps that NetSol was still the registry for .net -- that's out of date now, isn't it?

Uh, yeah, Verisign spun off the NetSol registrar over 20 years ago in late 2003.

In early 2003 Verisign turned .ORG over to PIR, but they kept .NET and .COM which they stil have. They are also the registry for a bunch of small ccTLDs and new gTLDs. They paid $135 million in the auction for .WEB which they may eventually run once the legal challenges are settled.

NetSol was bought and sold and merged several times and since 2011 has been part of web.com.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 4 Jul 2024, at 21:53, Crist Clark <cjc+nanog@pumpky.net> wrote:

 On the other side of this, we all may be learning the value of not having all of you NS records in a single zone with a domain under a single registrar.

The majority of real large DNS hosting providers have their authoritative under multiple TLDs, bar a couple of exceptions (Google Domains / Cloudflare if memory serves me well). I’d really curious to hear from them how they think about resilience and whether some sort of special protection has been added to their domains.

It appears that Reid Fishler via NANOG <redhead@lightning.net> said:

-=-=-=-=-=-

Network Solutions has decided to put our domain name on Client Hold due to a single phishing complaint about a web page, which happens to just be a page of information about another domain from bgp.he.net. Network Solutions has been contacted, and refuses to handle this issue in ANY expedited manner. Executives from Hurricane have been calling and emailing Network Solutions for HOURS trying to have this addressed. If anyone has an escalation contact at Network Solutions, please email it to me at redhead@lightning.net, or rfishler@he.net. Thanks.

Glad to see that they fixed it, but this would be a good time to remember why nobody who cares about their domain names would use Netsol. The usual choices for high value domains are Markmonitor and CSC. They cost more but sometimes it's worth it. (Not that Netsol is particularly cheap.) R's, John