Centroid.EU Blog

(this blog is mostly encrypted - adults only)
  

Previous Page


Planning on dumping 6 domain names, keeping 4

January 19th, 2019

I'm planning on dumping everything but these domain names:

  1. centroid.eu
  2. delphinusdns.org
  3. dtschland.eu (will remain a test zone)
  4. unspecified hosted domain name
What this means is that by July 2020 the others will all be expiring. 5 of the 6 are actually .de domain names and I'm saving quite a bit by not renewing. I view it all as a trimming the fat or consolidation effort. Since dtschland.eu was gotten a few years ago for 10 years I don't have to renew it but the other 3 I'm going to renew for two years or so.

To help with this effort I'm also going to be getting three new vps's and retiring two. The remaining I'm going to rename.

  • phi.virgostar.net -> red.centroid.eu
  • tau.virgostar.net -> blue.centroid.eu
The new VPS's I have already fixed at green.centroid.eu, vertex.centroid.eu, and triangle.centroid.eu. This means I'm giving up my previous naming scheme this is ok. I'm not going to have a scheme right now and just name stuff whatever I feel like. Since everything is based off virgostar.net right now I'm going to have to rename the nameservers. I hope to be finished by november with all this work.

0 comments

I'd be careful of Elon Musks Mars plans

January 18th, 2019

If you were asked to join Mars colonists by Elon Musk, you'd probably be excited. Would you be as excited if you knew you'd wear a microchip in your brain? This is what Elon Musk has prophesized that in order to "counter" the threat of an AI taking over humans and humans must adapt. It seems to me that humans who chip themselves lose their humanity.

I have heard rumours that we'll all be chipped some day and our actions would be pre-determined or pre-processed to be flag innocent or guilty of resisting the system. When we're chipped we'll be stripped of all humanity and we'll continue on as a new species. Not exactly promising. I personally think a PC would be enough for a human. If only there wasn't this problem with wear on eyes and fingers in order to interface. I'm quietly thinking around how a speech-hearing interface would be best done.

0 comments

Got a new switch

January 16th, 2019

I have taken fitch the HPE switch out active switches in the apartment. It's a datacenter switch and has a noise level of 45 decibels. I'll use it as such thankfully 10 Gbit Ethernet will be around for a while. I always wanted to colo somewhere so this is a step in that direction.

I have replaced fitch with snitch the netgear switch. It is a "GS110EMX - 8-Port Gigabit Ethernet Smart Managed Plus Switch with 2-Port 10G/Multi-Gig Uplinks" type switch. Notice I didn't want to get rid of my 10 GbE completely so I got them as uplinks. For now this will be OK. Thankfully it's fanless and doesn't make a noise. Funny that for a switch I named snitch.

0 comments

Rolling all KSK keys this week

January 14th, 2019

I'm rolling all KSK keys of my zones/domainnames this week. I started on virgostar.net today, I'm shifting each day 1 new domain name. Until saturday. I have 7 DNSSEC domain namenames and 2 I have already done. They were the test domains. Everything after today has services on it and I can't screw it up. Wish me luck!

0 comments

Reset all comments

January 12th, 2019

I have reset all comments in the blog. This is easier than going through the list of 600+ comments and seeing if there was XSS content. This is for your safety, however uninforming as some articles added to the content in articles. Sorry for any inconvenience. If you need to restore a comment there is an archive but please only ask me to restore it if it's a life vs. death situation.

0 comments

Delphinusdnsd performed two KSK rollovers over 30 hours

January 11th, 2019

I finally had the code right, but one KSK rollover was botched. This was due to the wrong instructions of RFC 6781 section 4.1.2. I should have looked in the Errata section of this RFC. The result due to the botched effort of rolling the KSK of the zone dtschland.eu is that if you got the DS key of this from the eu. nameservers it will not be validated because the old DNSKEY was rolled out in the dtschland.eu. zone.

The rollover should keep the old rolled out key around for 86400 seconds, as is being done for the freifunk-schweinfurt.de zone. Here is the listing of dnskey's of that zone:

beta$ dig @omega.virgostar.net dnskey freifunk-schweinfurt.de +dnssec |\
	 grep RRSIG | awk '{print $11}'         <
40824
59532
56933
These are the key pid's that are currently active. After tomorrow 18:00, the 59532 key can be safely removed.

I'm going to be working on all my DNSSEC'ed zones to roll ZSK and KSK over the next few weeks. I have services on some domain names so this process must work. I must work out any kinks before I do any such changes. Someone told me that RFC 7583 is important to read. Also I have written up the process for rolling a KSK with delphinusdnsd here in the delphinusdns.org's handbook.

0 comments

More XSS vulns

January 11th, 2019

I have been informed that there is more XSS vulns on my blog. This one was not as easy to solve as the last time I fixed XSS vulns. I had to actually write a bit of code. I noticed with this "double-sanitizing" that html code injections were possible through the search system not just XSS.

I have an open source blog this means you can see the changes. Here is the code history with comments. Enjoy, and sorry if you were vulnerable to an XSS attack.

0 comments

The endless debate around Computer-System security

January 6th, 2019

Recently in conversation it dawned on me that we're really stuck in a lake full of shit, and our boat is sinking. Let me explain. Person I talked to said that to drive a car he doesn't have to know about how the car functions in detail, he gets on the wheel and drives. A computer should be the same, you don't care about anti-virus, or security knowledge, you just get on and surf. He expects the government to do something in regards to the security. I don't share that viewpoint because the government would be invasively monitoring us all for the sake of security. It adds up to surveillance.

Similarily in infrastructure, we mentioned that powerplants should not be on the Internet. But in todays world powerplants have to be turned on and off depending on demand, and this needs to be signaled. So then I said why can't powerplants be on their own "internet" (small i) but not on the big Internet (big I). This is a costly solution, but also a safe solution. Because when the power is off because of hackers we wish it were so. Again the argument was that government should protect these companies and they should not care a damn about security themselves. Reality is they have an IT department that is supposed to take care of these, they are powerplants and have lots of money.

The BSI (Bundesamt fuer Sicherheit am Internet?) can only do certification programmes and guidelines, anything beyond that is again intrusive to everyones privacy and would be monitored en-masse. Should the BSI have the control that the BND in the Frankfurt IX currently enjoys? With firewalls all along the way managed by them (perhaps with help of an artificial intelligence)? I say no. We must keep this centralized component out of our Internet. Everyone has a responsibility to have an IT contact who gets paid full time to look over networks. It's the decentralized approach and is supposed to minimize mass surveillance. What do you think? Why don't you discuss this with your peers? We talked about a "family IT person" who looks after the families computers, is this good or bad? Everyone wants to squeeze money but security forces us to squeeze more than our wallets, we actually have to think to defend ourselves _and_ make decisions. We should not let the government do these decisions for us! Government is a control-freak and will make it the worst-case scenario for us all.

0 comments

Ambitious goal: have KSK's rotated by first week in February

January 5th, 2019

I have reviewed my code in dddctl.c of delphinusdnsd and determined for it to be mostly good. Next week I'll start coding on this again. I want to rotate my KSK keys of my DNSSEC zones by first week in February. I'm very so much looking forward to this day as it means that it's an important step in delphinusdnsd's development. Basically one could make keys back in 2015 but by now they are 4 years old and weakened by time. When I have done this work, I can look further toward other TODO's that I had planned.

Other things that the project needs is a clean-up of the website. The handbook is somewhat outdatedly using dd-convert.c still. This needs to be updated to use dddctl.c. It will be easy though.

0 comments

New redundant setup

January 4th, 2019

As you know my switch is very loud. Until I can fix it I have set up a redundant setup here at home, using trunk(4) and OSPF (ospfd). I'm gonna try to cover the configs here.

The hallway router's OSPF config looks like this:

router-id 0.0.0.2
redistribute default
redistribute 0.0.0.0/0

area 0.0.0.0 {
        interface trunk0 {
                auth-type simple
                auth-key $password
        }

        interface gif0 {
                metric 100
                auth-type simple
                auth-key $password
        }

}
The Office's OSPF setup looks like this:
router-id 0.0.0.3
fib-update yes
redistribute 192.168.35.0/24
redistribute 192.168.2.0/24
redistribute 192.168.177.3

area 0.0.0.0 {
        interface ix1 {
                auth-type simple
                auth-key $password
        }

        interface gif0 {
                metric 100
                router-priority 5
                auth-type simple
                auth-key $password
        }
}
This causes gif0 to go on when ix1 (switch) is not available, and reverts back to switch when it turns on. I have a timer on the switch, at a 12 hour Hz. Lastly the living room is not served with OSPF. It is just a trunk interface and looks like this:
uranus$ more /etc/hostname.trunk0
trunkport em0
trunkport em5
trunkproto failover
inet 192.168.177.40 255.255.255.0 192.168.177.255
inet6 autoconf
up
Trunk notices the link going from active to inactive and does a failover from trunkport em0 to trunkport em5 (which is connected directly to the router). It all seems to work out. There is a caveat. When ssh'ed from office to the Internet and OSPF returns back to the switch in the morning, the session expires because it came from the wifi's interface endpoint. Also when it's evening and the switch turns off, one has to clear the ARP cache in the office, because it still thinks 192.168.177.3 (my dns server) is on the local link. Once it is cleared it routes via wifi.

0 comments

Next Page

Search

RSS Feed

Click here for RSS

On this day in

Other links

Have feedback?

By clicking on the header of an article you will be served a cookie. If you do not agree to this do not click on the header. Thanks!

Using a text-based webbrowser?

... such as lynx? Welcome back it's working again for the time being.

Older Blog Entries


Powered by BCHS