161–170 of 179 posts
Both for safeguarding internal use, and making a global TLD reserved on the global DNS zones. You'll find organisations using in production .local .dev (Taken by Google on 2014-11-20, followed by .app in 2015) *.zone (Taken by a LLC on 2014-01-09 ) as internal domains, with potential conflicts with the Internet's DNS resolution.
More importantly .dev [1] and .zone [2] are now valid TLDs, so watch out people!
There was the time that Keith Henson tried to explain the local loopback address to Scientology lawyers during a deposition... http://www.cryonet.org/cgi-bin/dsp.cgi?msg=6289 Henson: (patiently) It's at 127.0.0.1. This is a loop back address. This is a troll. Lieberman: what's a troll? Henson: it comes from the fishing where you troll a bait along in the water and a fish will jump and bite the thing, and the idea of…
First, the lack of confidence that "localhost" actually resolves to the loopback interface encourages application developers to hard-code IP addresses like "127.0.0.1" in order to obtain certainty regarding routing. This causes problems in the transition from IPv4 to IPv6 (see problem 8 in [draft-ietf-sunset4-gapanalysis]). That does remind me of the times I was dealing with weird connection issues in some critical s…
Standards, practices, tradition, culture. They mean nothing when a devops lead has commit rights to the ansible playbook and a will to deliver a fix in 5 seconds flat.
Also very important to point out; this same standardisation is missing on the TLD level. Both for safeguarding internal use, and making a global TLD reserved on the global DNS zones. You'll find organisations using in production .local .dev (Taken by Google on 2014-11-20, followed by .app in 2015) *.zone (Taken by a LLC on 2014-01-09 ) as internal domains, with potential conflicts with the Internet's DNS resolution.…
Earlier quoted context omitted.
Or use a single socket for both protocols (set the IPV6_V6ONLY socket option to false).
That works when binding to :: (all interfaces), but it's irrelevant when binding to "localhost", because you can only bind one address per socket.
Also very important to point out; this same standardisation is missing on the TLD level. Both for safeguarding internal use, and making a global TLD reserved on the global DNS zones. You'll find organisations using in production .local .dev (Taken by Google on 2014-11-20, followed by .app in 2015) *.zone (Taken by a LLC on 2014-01-09 ) as internal domains, with potential conflicts with the Internet's DNS resolution.…
macOS has been using .app as its application extension for decades. Now when you want to search for a specific app on the browser you'll have to be more careful.
The fact that they allowed .dev, which is a fairly common TLD for development, is pretty unbelievable.
I haven't seen any evidence that by allowing companies to register these TLDs we've brought forth some kind of improvement or benefit to users.
There's a recent issue with TLDs that makes me particularly angry. There's ongoing work on this homenet spec. Originally it proposed using .home to route exclusively within the local network. But since .home is already used by a large number of people for private purposes, they changed it to .home.arpa. How the heck have we gotten to the point where we can justify allowing .google as a TLD, but we can't reserve something nice and short for non-companies?
Also very important to point out; this same standardisation is missing on the TLD level. Both for safeguarding internal use, and making a global TLD reserved on the global DNS zones. You'll find organisations using in production .local .dev (Taken by Google on 2014-11-20, followed by .app in 2015) *.zone (Taken by a LLC on 2014-01-09 ) as internal domains, with potential conflicts with the Internet's DNS resolution.…
* http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html
I would very much like to see this draft extended to cover SRV lookup as well. Right now, section 3 of this draft would prohibit all SRV queries for localhost, which may hinder development and deployment of a SRV based application. That's an immediate problem. But not only are there existing applications to which it is immediately applicable - it is a design error in HTTP that plain address records are used for resol…
* http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html
But what should such a standardized SRV lookup for _proto1._proto2.localhost. yield as the answer? For starters, what port numbers?
Earlier quoted context omitted.
It's called an I-D, for "Internet Draft." Very roughly, a Standards Track document in the IETF goes through four stages: 1. Someone submits an I-D as an individual. Literally anyone can do this and such a document carries no weight. 2. A working group (WG) "adopts" the I-D and proceeds to work on the document as a group. The document still carries no weight at this stage. 3. The I-D is published as an RFC. When this…
To be fair this is the fourth draft of "Let localhost be localhost". Internet Drafts deliberately "expire" unless you write an updated version every so often proving it's still interesting and being worked on. @agwa says they have "no weight" but pragmatically what matters is always whether people do what the document says, not its supposed "weight" within a standards body. For example many of you will have used Let'…