Being exposed to djbdns I was never tempted at all to try c-ares.

Not sure what I missed. It must have some other redeeming qualities besides this one. :)

Learning to master nc and tcpclient before curl* had the same effect. I guess I am missing all the fun.

*There are so many features, so much rarely used code, I'm not sure one could ever hope to fully understand all the implications.

"...turned off the WiFi entirely just using it as a switch + NAT combo."

I took this angle early on and have never had second thoughts. As they say, "It just works."

Glad you are seeing the benefits.

However, I think "WiFi" is a strong marketing signal. Even if it does not work as well as Ethernet at transferring data, it appears to work well to sell products and services.

"I really don't know how this tech is going to work..."

It may not have to work. Consumers of computing devices have developed a high tolerance for stuff that is either ridiculously slow or does not work. Many do not know any different: when none of the devices people use have an Ethernet port, they will never know the speeds they are missing. The choice of using Ethernet has been removed.

"... armour the requests themselves to make sure that they don't become the new vector, they don't become manipulated."

I interpreted this to mean encrypting each DNS packet.

Maybe I misread the statement?

DNSSEC of course does not protect the contents of the packet.

Instead, DNSSEC more or less is just another CA system (or an adjunct to the existing one), running over UDP.

You're confusing vanilla DNSSEC with its proposed uses/abuses. DNSSEC just enforces the trust model that was already in place (the hierarchical nature of DNS) to ensure the authority and integrity of DNS responses. It doesn't provide confidentiality because that simply doesn't work in the shared DNS forwarder+cache model we all currently depend upon, much like HTTPS renders shared HTTP caches useless (which has implications for CDNs for example).

Proposals like DANE, using TLSA records, or deploying SSHFP records on DNSSEC enabled domains, are a different kettle of fish.

Whether or not you believe in DANE really depends on whether you're willing to accept that the DNS infrastructure is already security critical. Truth be told, if I can hijack your DNS, I can get a certificate for your domain using simple domain validation... but that's true of your web server as well. There's no easy answer here.

That would be DPRIVE, which he mentioned as well -- http://datatracker.ietf.org/wg/dprive/charter/

Well, at least they are acknowledging the need.

I use my own cache, not shared with anyone. Do I really need to worry about snooping?

I also use CurveDNS with the authoritative server that serves my version of the root.zone.

Practicing my CurveDNS skills for that day when more authoritative servers are using curvedns. Not sure that day will ever come.

"... you can still buy IPv4 addresses for ~$12/ip."

About the price of a domainname? (Note I did not use the word "cost". I create dommainnames all the time at the price of $0.)

Given the choice between a domainname and an IPv4 adddress, I would take the IPv4 address.

Also, given the choice between a single, routable IPv4 addresses and a block of IPv6 addresses, I would still choose the IPv4 address.

IPv4 is "simplicity" in comparison to the complexity of IPv6. IPv6 has features I do not need.

Whenever I am granted the choice, I always choose simplicity over complexity.

Most of the time the additonal complexity is not needed and can only cause problems in the long run.

This is only the opinion of one "consumer". Certainly the "market" may have another opinion.

> "Also, given the choice between a single, routable IPv4 addresses and a block of IPv6 addresses, I would still choose the IPv4 address."

Ah yes, which would likely entail the 'simplicity' of NAT...

> IPv6 has features I do not need.

Are you forced to use them? If not, where's the problem?

I for one love ipv6, it restores the end-to-end principle.

They're likely referring to scenarios like this: https://news.ycombinator.com/item?id=8278864 - "IPv6 privacy addresses crashed the MIT CSAIL network" & the much more complicated host discovery / address assignment process on IPv6 segments. Still, I think I'd rather deal with some implementation kinks than intentional packet mangling like NAT.

> I create dommainnames all the time at the price of $0

Care to explain how?

I'm interested too. My guesses:

- http://www.freenom.com/

- work-for/own a domain registrar

- own a pseudo-TLD like .com.me and are really just creating subdomains

- have a large account / custom pricing deals with a domain registrar such that despite a high total cost, the marginal per-domain cost is approximately $0

- only internally-routable domains e.g. /etc/hosts or company-internal DNS server

- only alternative DNS roots like Namecoin or tor's .onion domains

How is v6 more complex than v4? It's simpler. Much simpler.

I wonder which "cloud hosting provider" they will choose.

Microsoft? Amazon?

Does it make a difference?

If my company starts selling cloud hosting and then I announce my company will be hosting its internal applications in "the cloud" (i.e., in my own data centers), what are the security implications for my company?

Are they the same if some other company asks me to host their applications in my data centers?

Is this article a PR piece (or "submarine" as PG calls it)?

What do you think?

> I wonder which "cloud hosting provider" they will choose.

Meant to be sarcastic? Google is in this market. Doesn't strike me that there is any chance they'd use MSFT or Amazon for infrastructure.

In a way, it seems similar to what Amazon did when they launched AWS.

Relies on DNS.

The birth of an optimizing assembler.

If you're curious, here is an optimizing assembler.

https://code.google.com/p/mao/

Butterfield: "It is because people say it is."

"Just because your services are dispatched through a smartphone doesn't make you a technology company."