There was a separate goto utility in early UNIX. Pretty sure you can still find the source code if you look. Meanwhile, it's mentioned here: http://www.in-ulm.de/~mascheck/bourne/
One of his two nameservers, ns2.missoulaweb.com (66.235.178.171), is non-responsive. The other one works but it's listed second. No round-robin. That can slow down the DNS lookup, as the first listed nameserver will likely be tried first, adding to the "slowness" of a website.
Dead nameservers are relatively rare among sites that get posted to HN, since many are high traffic and use CDNs (that rely on DNS kludges). But it is still a regular occurrence. No one ever talks about it. But it's one of the DNS kludges that's continually slowing things down behind the scenes.
There is that term "link rot" for URL's that do not work anymore. And "bit rot" for source code. I propose a new one: "NS rot".
What language are they using for cleaning up the data for import?
Is there a market for a middleman (i.e., something as a service) that cleans up enterprise data, using customized solutions if necessary, for import into different databases?
If this type of company already exists who are some examples?
This is very unsexy work which I happen to enjoy. Its the phase that routinely comprises 80% or more of any so-called "Big Data" project.
This is a more accurate description IMO. However DNS does not have to be that way. Before DNS there used to be file sharing of all the data via a single file in the simple "HOSTS file" format. Then there was a feature in DNS for sharing all the data of each nameserver, in a "zone file" format. With network bandwidth as it is today, sharing of data in bulk could be quite useful to make DNS more peer-to-peer like. People still share data, e.g., block lists. But, practically speaking, everyone running a nameserver connected to the public internet disables axfr.
Also, in my view peer-to-peer supernodes do not monitor or forward all data, they only maintain address information of the peers (rendezvous as you say). DNS, as it is implemented on the public internet, is ripe with passive monitoring as all data flows through centralised points in the tree. Leaves, at the network's edge, are expected to be "dumb", needing to make hundreds single requests for the same information, 365 days per year, even when the majority of it is relatively static.
Every query and response packet containing a seemingly useless "Query" field that never varies from "1". There's no pipelining (when using TCP) or packets containing more than one query.
From what I understand there was interest in so-called "P2P DNS" in reaction to various incidents of censorship via the centralised points in the tree. If the leaves were truly connected as "peers", and sharing the database data directly "peer to peer", then we might have better protections against censorship.
Incidentally, "DNSSEC", as advertised, appears to anticipate centralisation and usage as a CA-like system where peers at the network edge are not only dumb but incapable or verifying messages themselves without involvement of third parties.
In contrast, encrypting DNS packets requires no third party assistance. It can be done by peers all by themselves. A client can encrypt queries and a nameserver can encrypt replies. Well suited to peer-to-peer style usage of DNS. Bulk DNS data can be rysnc'd between peers over SSH, or perhaps mrysnc'd among groups of peers.
There is "DNS" as implemented so far and then there is "what's possible" using DNS. Peer to peer sharing of the data is hardly far-fetched. But it does not yet seem to have caught on outside of small groups doing passive monitoring, blocking and other manipulation.
I'd prefer to see decentralized email before "encrypted" email.
Recipient runs qmail listening for connections on some personally chosen port from among 1000's of choices. She is also running a firewall such as pf. authpf might also be useful.
Recipient tells sender her chosen port number and a personally chosen address to use. How does she do this? In person. Through the postal mail. Over the telephone. But _not_ over the Internet. Of course she does not have to use the same port and address for every sender.
In addition to the potential randomness of the port, the address she chooses could be any string of legal characters up to 250 whatever in length.
The approved sender runs qmail to connect to recpient's qmail and leaves a message on recpient's computer.
No DNS. No "email provider". No POP3.
How two users can discover each others' IP address and connect to each other through firewalls _without forwarding traffic through a third party server_ is left an as exercise for the reader. Chances are most users have used software that does this at one time or another, maybe without even knowing it. The methods have been around for decades. It works.
Centralized DNS and the need for a "domain name" is not needed.
Centralized "email providers" who store users' email are not needed.
There are a number of disadvantages and limitations to this approach. Yes, I know what they are. But I have already tested this and it works so I'm biased.
My opinion is that the _advantanges_ of "peer-to-peer", SMTP-to-SMTP email easily outweigh the disadvantages of store and forward and POP3 and make this a useful _alternative_ (not a replacement) system for centralized email. It's an _option_ users could have that would be quite useful.
The status quo approach to email has become highly centralized in both the need for ICANN DNS and "email providers". Not to mention the commercialization of email and the need to have "permission" to be able to send mail "because of" the proliferation of spam. It's far too difficult for any user to control their own email under the current centralized system. Solution: Give users another system where they _can_ control their email.
IMHO the centralization and protectionism of the current system (email is a business, but it doesn't need to be) is a bigger problem than lack of encryption. It's also what makes spamming viable. Everyone knows your email address or can get it easily enough. In many cases, that is not necessary.
As it stands, email is concentrated in a limited number of locations (the servers of email providers), transferred over a few ports (25, etc.) and users are limited in the addresses they can use (commercially registered domainnames).
I can think of worse outcomes than having to use djb's software, whether it's dummy-proof libraries, well-designed, small programs that work together, or algorithms chosen as defaults by some self-authorized standards group or by a company selling bloated, proprietary software that only works with other programs written by that company.
"So the RPi foundation deliver the first mass-market hackable board,..."
I notice this type of negative comment about inexpensive, "hackable" hardware freqently on HN. As if the fact that a piece of hardware is inexpensive and "hackable" is insignificant. Perhaps to these commenters, it is. But to others it may be signifcant.
A pocket-sized computer with networking that boots _either_ a GNU/Linux project, a BSD project or Plan 9, not to mention a few other open source OS, from an SD card. For me, this is the major advance and appeal of the RPi.
Far from perfect but still a major advance from the previous status quo, IMHO. Thank you RPi.
In a sense RPi is a market maker. Now they have to find ways to compete in the market they made.
Right on. I remember using a VAX in the 1980's and it still seems like the fastest computer I ever used. Everything that came after seemed sluggish by comparison. Then many years ago I tried someone's VAX image in the simh simulator running on on MS Windows. It was "too fast", if there is such a thing. I want a pocket-sized VAX.
"I will set up any network I'm in charge of with a DNS that has doubleclick.com as 127.0.0.1, and also many others."
You mean doubleclick.net? Alas, that's a typo that would let the ads in.
Like you I redirect doubleclick and "many others". But not to localhost. I like to log all the requests either via pflog or a socket logger. Useful for examining what apps are trying to do from my device over the network. Sometimes I redirect certain domains to my own httpd and serve my own "fake" resources (placeholders for in-app ads, etc.).
You say "any network I'm in charge of".
What if there were a DNS caching server reachable from anywhere that blocked these ad servers for you? That is, what if there was a "public DNS" like 8.8.8.8 or 208.67.222.222 except not run by a company that sells ads or "security services"?
What if there was a turnkey ad-blocking DNS caching server solution that one could run on any suitable hosting provider virtual machine instance?
Would anyone be interested in such a thing? I have had this personal DNS idea for many years, ad blocking is becoming much more popular only recently.
I think users controlling their own DNS is a key step toward taking back the www from the "corporate dreck". Maybe blocking ads is the stimulus for such a change.
1. The truth is, I make far fewer queries than the average web user. Because I have the IP addresses I need stored permanently. And I only update those files periodically. Today's websites and graphical web browsers (that I do not use) perform astounding quantities of uneccessary _daily_ or _hourly_ DNS requests that I never make. Maybe you think I am resolving every registered name in existence? If that were true, then yes, I think that is unreasonable. But the fact is I am only resolving the names I need, which, in the context of the total number of names registered, is very, very few.
however scans.io and other scanning projects do not seem to be labeled as "unfriendly" nor the target of "hate"; perhaps your views are not based on actual exerience?
2. This is a personal solution. I am not writing software for anyone else. I do not have to use TCP for DNS queries and I have never found an authoritative server that refused to accept a UDP query. dnsq does not do TCP queries; I guess you could complain to the author he's violating some rule? If I am not mistaken, amplification problems happen because of ideas like open resolvers and enormous UDP packets, like those required for EDNS0 and DNSSEC. I am not a user of either of those ideas.
Back in 2008 after the cache poisoning hype, I developed my own method of resolving names without using caches (it is very fast); I use only authoritative servers. I still use this method daily.
"... but we can set the tc "Truncation" bit to force an upgrade to the protocol with more bandwidth."
dnsq does not do TCP queries. Sorry.
I also developed a few systems for resolving all the names I needed in advance so I did not need to use DNS at all, except when periodically updating the list of IP addresses. I am glad I did that work. (But nowadays there are resources like scans.io)
When someone publishes a vulnerability in dnsq from djbdns (it does not send recursive requests), I'll have to dream up another solution to the problem of "DNS". I doubt that's going to happen, but I could be wrong.
"The fact that djbdns doesn't use BIND code is not really relevant."
It is to me.
It's true that in this case it's not what mitigates this vulnerability. Although it has certainly mitigated many others over the years and, sadly, probably will do so a few more times in the future. There's just no getting rid of the BIND legacy.
Correct me if I am wrong, but using a local dnscache and the fact that dnscache does not implement ENDS0 should be enough to mitigate this one.
I have been running a local tinydns root.zone and dnscache for many years. Really like the software.
There are certainly more you omitted (similar to your code CDN for javascipt, fonts, etc.)... consider something like recaptcha.
In my experience, all those requests to api.recaptcha.net get forwarded to "www.google.com"
My experience has been that if a user for whatever reason cannot access the IP du jour for www.google.com (www.google.[cctld] will not suffice) then that user is prevented from using the myriad websites that rely on recpatcha.net.
Now, I could be wrong and maybe there is something I am missing, but in my experience this is a sad state of centralization and reliance by websites on Google. Quite brittle.