kijeda

Amongst other problems, that limits TLDs to 6 characters, which is about 16 characters shy of the longest TLD right now in the DNS root zone: https://data.iana.org/TLD/tlds-alpha-by-domain.txt

Add to that the fact it would fail on a legitimate top-level domain like .рф or .中国.

I find it intriguing that the same article manages to spell her last name Wojcocki (5x), Wojcicki (2x), Wojciki (1x) and Wojocki (1x). It would appear of 9 references, her name is spelled correctly only twice.

Perhaps there is an opportunity in this fast-to-publish world, in the absence of editing or spell-checking, to develop tools to contextually sanity check proper nouns before posting.

ICANN is not in a position to mandate such requirements for ccTLDs as they are not empowered to. ccTLD governance differs from gTLDs in that each country code is managed and overseen locally within the country. This is why there is such a diversity in ccTLD policies. For better or worse this model of subsidiarity is what we have today.

The IAB put out a statement “Dotless Domains Considered Harmful” that explains some of the risks if ICANN changed the rules to allow them. As it stands, they were already prohibited and this resolution reaffirms that.

http://www.iab.org/documents/correspondence-reports-document...

Well, sure, just like I can create my invented domain name like hacker.news and use my own IP addresse 1.2.3.4 without being allocated them. The Internet interoperates by everyone agreeing to follow the same agreed conventions, but there is no rule that says you have to. The registry for HTTP status codes has no 420 code and could be assigned for a different purpose in the future: http://www.iana.org/assignments/http-status-codes

It only implements a subset of DNS functionality, so I'd argue its giving a false sense of security and false negatives. mailtest@пример.испытание fails, for example, even though it is a valid email address.

If you are using the .COM zone data (note this is different from the root data), then it is an incomplete list of all the TLDs that are registered. It is only a list of domains that have been delegated.

IANA blocked registration of most of them under gTLDs (.COM, .NET, etc.) in 1993, on the thought they may be useful to support extensibility of the DNS down the track. Country-code operators have typically followed that lead as good practice.

As they were never really used for that purpose, slowly but surely they have been released into circulation. The applications by registry operators to lift the one- and two-letter domain restrictions are at http://www.icann.org/en/resources/registries/rsep

It is probably worth noting the latest version of the IDN protocol (RFC 5891) makes this URL illegal. It will only work with implementations that use the earlier deprecated version (RFC 3490).

That is some terrible revisionist history.

.com, .net, .gov etc. were the first TLDs created in the early 1980s (when the DNS was invented, before ICANN existed). Only later in the mid 1980s were country codes added to the repertoire, and each country was given one based on the ISO 3166 standard — including the US (.us).

The only domains with geographic prohibitions were .gov and .mil, being run by the US Government. People of all countries have always been able to register domains in .com, .net etc., not just Americans.

This map would be more useful if instead of each bus being represented by a nondescript MUNI logo, that it was an icon that contained the route number. As it stands it appears the only way to get useful information is to hover over each logo to work out what it represents.

The article states "law is perhaps the only field where being a pessimist is actually an advantage", but I actually find this is an attribute that programmers and lawyers share. In developing code, one is always trying to think of all the possible inputs and outputs includes the unintended corner cases in order to write robust code.

I would say the two professions are more alike than credit is given, and working as a programmer in a lawyer-heavy firm, I've often been told by those in the legal profession that programmers have the ability to think logically stepwise through law more clearly than others.

Yes, it is "THAI CHARACTER KO KAI" (U+0E01), plus 20 occurrences of the non-spacing mark "THAI CHARACTER THAI CHARACTER MAITAIKHU" (U+0E47).

It seems to me to be a cop-out to suggest you can't have good public transport in a low density area. I come from the city of Perth in Australia which is very sparse and it has managed to create a very good intermodal system with light-rail corridors connected by an extensive bus system that feeds to the rail system. You can get pretty much from anywhere in the city to anywhere else with a bus service within half-a-mile, often involving trips of 50 miles or more.

While Google Maps' colors don't make it easy to visualize, perhaps you can get a sense of it: https://maps.google.com/maps?q=Perth,+Australia&hl=en...

I noticed a bug in another tool today, caused by the week-of-the-year value returned by strftime() returning '00' until the 6th. Possibly related?

This list is out of date - it contains strings that have already been withdrawn by the applicant. The accurate list, including status, and the prioritization order (the order they'll be added if successful), is at:

http://gtldresult.icann.org/application-result/applicationst...

I find this mentality, one I've often found in the US, disturbing.

I've had the benefit of living the better part of a decade in Europe where data privacy protections are stronger, and there is a resulting expectation that companies can only do with customer-provided data what they had agreed to when it was supplied. That means only using data for the explicit purpose it was gathered and not changing or using the data for expanded purposes later.

It is bizarre to me to think that one should just accept that the receiver of the data can unilaterally expand the use of it later without informed mutual agreement.

That is because Donuts applied for its gTLDs through a number of LLCs with names like "Delta Mill, LLC" and "Snow Sky, LLC". You can find a great many of them objected to.

If you have a routing issue, whether it is due to "corruption" or misconfiguration, having some of your name servers on an entirely different network (i.e. a different AS) with a different routing policy is not going to be affected.

The DNS is designed to provide resiliency to these kinds of problems by providing the ability to list multiple NS records located in different networks. It is standard practice for top-level domain operators and other high-activity domains to place their name servers in different networks to guard against these kinds of issues. When companies put all their name servers in the same network, they are removing the diversity benefit and create a single point of failure. Domain operators should take this as a cautionary tale that they shouldn't have all their eggs in one basket and make sure a single network failure couldn't take all their name servers offline.

That is not correct. For example, Mozilla takes a white list approach where they add TLDs that have registration policies that limit the risk of phishing (which is most of them).

http://www.mozilla.org/projects/security/tld-idn-policy-list...

One of the common refrains from this is that it is a money grab by ICANN, but all ICANN is doing is implementing a multi-stakeholder consensus policy that was ratified by the various community groups 5 years ago, and doing so on a cost-recovery basis. While the costs may end up being conservatively estimated, any excess will be returned back to the community.

ICANN itself has no vested interest in this other than executing its policies, and if the consensus policy had ended up being "no new gTLDs, there are enough" then it wouldn't have embarked on this program.

The review process is conducted by multiple outside firms that tendered in an open process for the right to review the gTLD bids.

It would have more utility if in the search box you could type the RFC/BCP/STD number, e.g. "1591" or "STD 3".

Unfortunately every RFC I tried, except for the provided examples, returned "Could not prettify this RFC".

Isn't the issue, then, that you shouldn't be put in jail for such offences, rather than making arguments concerning strip searching?

Actually, the other thread of discussion throughout the week is that IETF attendees at the Concorde Lafayette hotel have been regularly having their rooms burgled. The hotel has not been proactive responding to it, and arguably has been turning a blind eye.

So, more like lumps of coal.

No. The database was already in the process of being transitioned to IANA prior to the lawsuit. The lawsuit just accelerated the transition. It is now at http://www.iana.org/time-zones

Various technical experts from the DNSSEC/ICANN communities published a paper about six months ago on the problems the remedies can cause for DNSSEC. See http://s3.amazonaws.com/dmk/PROTECT-IP-Technical-Whitepaper-...

In essence, any measure that involves changing the contents of the DNS (by filtering etc.) is indistinguishable from a man-in-the-middle attack which is what DNSSEC is trying to stop.

It seems like this is a provisioning trick, rather than an actual DNS record. None of this "ALIAS" records ends up in a zone, or in a DNS packet; rather it is some option on a web interface that presumably never comes near the actual DNS because it is provisioned as something else.

I'm curious, if you point such an ALIAS to a service that dynamically returns different IP addresses based on location; what this service is going to do.