<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: TLDRisk</title><link>https://news.ycombinator.com/user?id=TLDRisk</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 10 Jun 2026 03:59:42 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=TLDRisk" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by TLDRisk in "Never buy a .online domain"]]></title><description><![CDATA[
<p>It's the registry, not the registrar.  I made a website that tries to help explain some of the lesser known nuances and risks relating to domains.  The section about domain reclassification is based on first hand experience and is especially interesting IMO:<p><a href="https://tldrisk.com/beyond-basics/reclassification/" rel="nofollow">https://tldrisk.com/beyond-basics/reclassification/</a><p>> This basically makes the entire TLD unviable for serious use.<p>It doesn't just make the TLD in question unusable.  I think it makes most of the new gTLDs unusable.  Registries can enact policies and systems like this, regardless of the detriment to registrants, due to a lack of oversight and registrant consideration by ICANN.  That creates uncertainty and makes it pragmatic for registrants to simply choose the gTLDs with lots of history and precedence; .com, .org, etc..<p>The only two TLDs I'd personally rely on are .com (gTLD) and .ca (ccTLD).</p>
]]></description><pubDate>Wed, 25 Feb 2026 22:51:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=47159191</link><dc:creator>TLDRisk</dc:creator><comments>https://news.ycombinator.com/item?id=47159191</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47159191</guid></item><item><title><![CDATA[New comment by TLDRisk in "From .com to .anything: Top-Level Domain (TLD) Insights on Cloudflare Radar"]]></title><description><![CDATA[
<p>It's almost impossible to judge based on the pricing alone.  Paying top dollar doesn't guarantee anything extra and low prices don't always mean low quality service.<p>$6.99 looks like a first year discount at dynadot with renewals at $10.88 USD.<p>> Why such a huge difference?<p>A lot of registrants don't know what the wholesale pricing looks like and the difference between $10 or $25 / year for a business isn't a factor.  The risk that comes along with transferring to a cheaper registrar isn't worth it to save $15 / year.</p>
]]></description><pubDate>Tue, 28 Oct 2025 00:09:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=45727894</link><dc:creator>TLDRisk</dc:creator><comments>https://news.ycombinator.com/item?id=45727894</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45727894</guid></item><item><title><![CDATA[New comment by TLDRisk in "From .com to .anything: Top-Level Domain (TLD) Insights on Cloudflare Radar"]]></title><description><![CDATA[
<p>> And what happens if your domain gets popular, are they going to just jack up your rent from $25/yr to $500/yr or more?<p>As long as your domain is in the standard fee class, aka non-premium, they can't target it for a price increase if it's a gTLD.  They have to raise the price of all standard domains at the same time.<p>Everyone will tell you they can't reclassify a domain from standard to premium, but that's not technically correct.  They can change the classification to whatever they want, but they have to charge you standard renewal fees if the domain had a standard classification when you registered it, as long as you haven't let it expire.<p>I created a website that has some info about domain reclassification.<p><a href="https://tldrisk.com/beyond-basics/reclassification/" rel="nofollow">https://tldrisk.com/beyond-basics/reclassification/</a></p>
]]></description><pubDate>Mon, 27 Oct 2025 22:42:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=45727190</link><dc:creator>TLDRisk</dc:creator><comments>https://news.ycombinator.com/item?id=45727190</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45727190</guid></item><item><title><![CDATA[New comment by TLDRisk in "PyPI Preventing Domain Resurrection Attacks"]]></title><description><![CDATA[
<p>The ERRP only covers gTLDs, right?  Have you seen any ICANN policies requiring ccTLDs to adopt the same grace periods.  As far as I know, ccTLDs can do whatever they want.</p>
]]></description><pubDate>Tue, 19 Aug 2025 21:58:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=44956649</link><dc:creator>TLDRisk</dc:creator><comments>https://news.ycombinator.com/item?id=44956649</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44956649</guid></item><item><title><![CDATA[New comment by TLDRisk in "PyPI Preventing Domain Resurrection Attacks"]]></title><description><![CDATA[
<p>Domain expiration is something that's more complicated than most people realize.  As an example, I'm not sure if there's a definitive source stating that auto-renew grace is part of the ERRP.  In my opinion it's not and the ERRP typically won't trigger for high value domains because they'll be sold or auctioned by the registrar instead.<p>As far as I know, the ERRP rules describe the policies for the <i>deletion</i> of expired domains, which isn't required, so working off the auto-renew grace status was a good choice here.  Most people don't realize that expired domains aren't guaranteed to go through the ERRP lifecycle [1].<p>> You should be aware that during the auto-renew period, the domain name <i>may be available to third parties for registration</i>, depending on your registrar's terms of service. You may also run the risk of having your domain name auctioned to a third party by your registrar during this period (depending on your terms of service)<p>The process described here sounds like a pretty reasonable approach to a hard problem.  It won't catch everything, but it's a good approach and it's nice to see some effort put into the issue.<p>1. <a href="https://www.icann.org/resources/pages/registrant-about-errp-2018-12-07-en" rel="nofollow">https://www.icann.org/resources/pages/registrant-about-errp-...</a></p>
]]></description><pubDate>Tue, 19 Aug 2025 21:47:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=44956571</link><dc:creator>TLDRisk</dc:creator><comments>https://news.ycombinator.com/item?id=44956571</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44956571</guid></item></channel></rss>