|2019-03-06 17:20:37, 2 weeks ago|
|The 'backup dns' implementation is in the process of being relocated, and will be coming online with a new IP address.|
A notification with the new IP will be sent to affected users.
|2018-07-19 21:11:53, 8 months ago|
|Thank you members for your generous support during Hurricane Harvey's fundraiser last year!|
Most of it went to All Hands and Hearts (an all volunteer non-profit organization).
The remaining portion went to the HEB grocery chain, they were swift on the scene with deployments of mobile kitchens based on their emergency preparedness plan out of the gate.
|2018-06-13 13:51:30, 9 months ago|
|Maintenance has been in progress for ns1. since yesterday morning.|
The datacenter performed scheduled maintenance around 2AM, physically moving the server (the entire physical rack) within their datacenter, and it seems for one reason or another, the system did not survive the move, and was damaged in the process.
It is in the process of being rebuilt and brought online now.
Impact: This has had some effects on the IPv6-only update interface, and the nightly broken check, and to outgoing mails. These affected items should now be restored.
|2017-09-04 22:18:45, 1 year ago|
|Not DNS related, but a PSA... did you know the EPA mandates your local water be tested and those results be made available to you? I learned my water company published this data which contains numerous carcinogens and some registered radioactivity that is being fed to the region. Check yours, and respond appropriately to protect you and your family. Much of the contamination is not on purpose, there's no conspiracy, but is still an issue. Take advantage of the data in your area to make well informed decisions.|
|2017-04-09 14:19:50, 1 year ago|
|Support for CAA records has been added.|
|2017-02-23 10:56:20, 2 years ago|
|The web forwarder where free accounts live is on a network which is having a problem since this AM. They are working to resolve the issue, and I am continuing to monitor the situation with them.|
As a reminder having a premium account here does use multiple web forwarding servers for redundancy, and are provisioned immediately.
|2016-11-18 14:15:10, 2 years ago|
|mooo.com was yanked from freedns.afraid.org by the registrar this AM. I was able to re-acquire delegation again very rapidly and sort out the details with the registrar and confirm delegations were corrected around 11AM today. A users site on this domain created the issue that led to it.|
Due to DNS caching there may be lingering effects on some networks, which is normal anytime any domain nameserver delegations are messed with for any domain for any reason - this is because TLD level caching at the .com level, not because the issue hasn't already been fixed several hours ago.
Unfortunately I had no warning, I did share about the disproportional impact to my users due to DNS caching to the registrar, hopefully such a issue does not re-occur. They have not given me much trouble in the past for many years of reliable service however I do not want this to happen again from them.
I also want to say thank you for several of you very proactive/responsive in observing and quickly emailing me about it, which I sincerely appreciate, even though I couldn't individually respond at that moment - it absolutely painted a very clear picture very quickly and helped get it rapidly restored and I consider your messages helpful to the process.
|2016-03-10 10:40:07, 3 years ago|
|The web forwarder where free accounts live is on a network which is having a problem today. Their site and ticket system are down, but they have acknowledged the problem on Twitter and are working to restore it.|
If you run a critical service, having a premium account here does use multiple web forwarding servers for redundancy, and are provisioned immediately.
|2016-03-05 07:01:39, 3 years ago|
|As of yesterday all of your dns modifications are being done via a dedicated SSD of its own, which has improved the responsiveness of the site and web interface by increasing the amount of available storage throughput.|
|2016-02-17 21:31:33, 3 years ago|
|The dynamic dns interface now has native IPv6 support, and shorter update URLs available, check out version 2 in the dynamic dns section.|
|2014-11-13 21:14:01, 4 years ago|
|Hey guys.. I hope you're having fun with all of your sites/projects! I have really enjoyed running this project, and chatting with many of you when you've had questions.|
Not a lot to report here, just thinking about you all and your cool projects, and the impact you've had on me.
I did recently re-implement the synchronization system (this is the 3rd 'from the ground up' re-design).
The last sync system (sync-v2) worked faithfully for about 7 years - it was a 'chat' system, where all slaves listened on a persistent live socket for something to happen. This was awesome for years - at the time, it spent a lot of the time waiting for something to happen. The strength was that it could immediately implement a DNS change the very second it occurred.
Over time (this year), something happened, though (a good problem, really...). More updates were happening faster then it could keep up with occasionally at brief times. I started to notice occasional periods where a lot of updates were occurring, and some of the most latency/distant slaves were falling behind. The killer was the round-trip latency. This was firing all kinds of alarms and alerts to me. Rarely did a user notice, but I did, and when I started investigating, thats what I would find.
Stability and synchronization are really important to me, and I felt like the last design was starting to get challenged by a busy pipeline.
Enter the new design (sync-v3)! Now, rather then a persistent socket / chat system, all changes are bundled together and stored in RAM, and shoved down a socket in one direction as a single bundle/blob each 5 seconds, and replayed on the slaves from a single staged journal. This is great because its no longer a round trip/chat type of implementation. Its wrapping up all of the changes into a single burst, and shoving them down the pipe at once. It took me about 2 weeks to reach the new design, and about 4 days implementing it. Isn't it funny how more time goes into thinking about things, then actually doing things? (Anyone else experience this?) I'm happy to report the transition to the new implementation seems to be working quite well!
I'd like to say thanks for your continued premium support! Still zero ads here! Aiming to continue providing a awesome real time utility for you all, inline with my beliefs on what the Internet should be like.
|2014-08-30 11:02:26, 4 years ago|
|The web interface was unreachable last night starting around 4AM. I saw that I was running low on disk space leading up to it - but I thought I had a bit more time before running out, sorry for the inconvenience. This was corrected first thing this AM, I have freed a whole lot of space since then. (DNS resolution was not affected).|
|2014-06-27 16:43:10, 4 years ago|
|NS4 has been placed into maintenance for a hard disk replacement.|
|2014-04-19 19:29:28, 4 years ago|
|The web forwards that free accounts reside on has been unavailable today. I became immediately aware of the issue, they are continuing to work to restore service.|
The web forwards for premium users that are supporting freedns.afraid.org continue to function via a redundant path. If you choose to activate a premium account of any size your web forwards will immediately be copied and activated into the redundant system (this has been true for some time).
|2014-04-14 21:45:05, 4 years ago|
|I'm glad to report tonights maintenance disruptions were in the name of performance tuning, and it has been fruitful and has reduced server load.|
I am no longer seeing those mini-connection pileups at some of those busy moments.
|2014-04-14 21:39:43, 4 years ago|
|I've gotten a few questions regarding the heartbleed bug CVE-2014-0160 - freedns.afraid.org was not running any vulnerable versions of OpenSSL, and therefore was not affected, thankfully. All systems were assessed upon hearing the news. That was one nasty bug!|
|2014-02-22 14:31:05, 5 years ago|
|ns2. encountered a failed disk and was offline. It has been reinstalled and online today with a new disk and put back into service.|
|2013-08-18 03:01:09, 5 years ago|
|Database rebuild this AM has been completed, which took about 3 hours. This process freed up a lot of space that was being held by the db engine. |
The primary config was modified so such space is compartmentalized, and easier to incrementally trim in the future.
|2013-07-21 06:01:16, 5 years ago|
|ns4 has encountered a failed hard disk a short while ago, and is in the process of being rebuilt.|
|2013-06-08 11:04:08, 5 years ago|
|The resolvers are receiving heavy amounts of traffic, appears ongoing. I was online at the time it started, and responded immediately when it started. I am continuing to monitor it.|
UPDATE: Looks like levels have returned to normal.
|2013-04-30 18:54:32, 5 years ago|
|Replaced a failed disk in the primary server today. The user interface had experienced some disruption during this process while data synchronization was performed.|
kernel: ad6: FAILURE - READ_DMA48 status=51READY,DSC,ERROR error=40UNCORRECTABLE LBA=2593909119
|2012-07-21 17:18:06, 6 years ago|
|Yesterday ns4.afraid.org started experiencing bad sectors on its hard disk, first there was 3, then 5, then 10, then 13 within 12 hours. Monitoring caught this early before any data errors. Today there is 54.|
I am working on having a replacement disk up and running tonight, it will be unreachable during this time, however DNS will continue to function via the other systems.
|2012-04-23 13:21:52, 6 years ago|
|I saw a flood today directed toward all of the DNS servers. I moved traffic to bring service back up as quickly as I could.|
The attack is still ongoing, service has been restored, I am continuing to monitor it.
|2012-04-13 23:35:51, 6 years ago|
|Yesterday the frontend webserver and mail server crashed with a disk device failure. While monitoring for many early indicators, there was no warning with this that I could see. I was online at the time, and moved web traffic elsewhere within a few minutes, and today I moved mail to a different host all together.|
I've been messing with the recovery of it this afternoon/evening, the old drive in the last system appears to be pretty well done.
g_vfs_done():ad10s1a[READ(offset=-1150950322940674048, length=16384)]error = 5
g_vfs_done():ad10s1a[READ(offset=-1150950322940674048, length=16384)]error = 5
g_vfs_done():ad10s1a[READ(offset=-1150950322940674048, length=16384)]error = 5
/dev/ad10s1a 929779968 -217577473051816644 217577473907214216 -25435830095% /mnt/toasted
|2012-03-29 18:20:33, 6 years ago|
|Free accounts not accessed at least once every 6 months will be considered dormant and unloaded from memory.|
This is meant to keep a handle on some of the long tail account buildup that has accumulated over a period of several years. I am setting up a system of graceful notifications for this. This will not apply to premium members supporting the project.
|2012-02-22 19:23:52, 7 years ago|
|I am in the process of adding more capacity for the premium users, and making some major changes for increased stability. This will be available soon, I am excited to roll it out. Thanks for those who are supporting the project with premium memberships.|
ns1 is at a moved address still, its original continues to see heavy amounts of malicious traffic that is being successfully mitigated, once the malicious traffic subsides, it will be moved back.
|2012-02-17 12:19:06, 7 years ago|
|Service is restored to ns2 ns3 ns4 filtering was mitigating some of it happening for many hours through the night, now no more malicious queries are happening and levels are back to normal. I will be moving traffic back to the original IPs in the short term.|
ns1 has a hardware issue I am pretty sure, its taking some time to get it narrowed down though. The datacenter required me to format the entire server for the IRQ storm issue where the IRQ is associated with one of the 2 bonded nic's. I think its bad nic/port/cable/driver, they would not look any further until I formatted it. This happened to be at the same time as the other servers all fell under attack targeted toward some user's site - not at all related to the IRQ problem, so I thought they were blaming the attack on the previous IRQ storm issue wrongly, and that caused some confusion in our discussions.
Levels are flowing normal while this rebuild happens on ns1 which was unfortunate timing for it to have a issue of its own. I could have put that additional capacity to use yesterday/last night. It is the newest server, and I am certain would have contributed. Once things settle down here I will work on some longer term changes.
|2012-02-16 18:57:18, 7 years ago|
|Service is partially restored, I expect will be fully restored soon. ns3 and ns4 have both been moved, ns1 is currently disconnected due to provider seemingly confusing yesterday's issue with todays, the problem domain has been pulled at the TLD level, complete restoration is still ongoing.|
|2012-02-16 15:23:06, 7 years ago|
|We are experiencing a flood of queries incoming to someone's domain, ns3. has been moved to a different IP, working to restore service.|
|2012-02-15 23:11:00, 7 years ago|
|One of ns1.afraid.org's network devices started experiencing a IRQ storm in what looks like a bad network card or possible driver issue.|
This curiosity was quickly discovered as it caused network flooding over 1 million packets per second and had to be disconnected from the network as to not disrupt other systems.
DNS continues to function via the other servers while ns1 is under restorative maintenance.
|2011-11-09 20:39:23, 7 years ago|
|I have received reports of Google seeing DNS timeouts from users as of Oct 31. |
This has been identified and fixed. The issue was queries were coming in, but responses were leaving on the wrong network, and packets were likely getting dropped within the ISP's network. Unfortunately, the monitoring system still saw the DNS traffic activity, and reported All OK.
To keep this from happening again, I have coded in some changes to the monitoring system. The health check is now sourced from a secondary IP on an external network which is forwarded to the alternate instance (instead of just a local test on each DNS server, as I had been doing prior). The effect, is to require the responses to traverse the Internet with an answer that exists only exclusively in the alternate instance, before the service can be considered OK.
Thanks for those who have reported the issue. Such a case will now raise an internal notification.
|2011-11-09 16:49:48, 7 years ago|
|ns3.afraid.org is receiving a memory upgrade this evening. It will return online shortly with twice the memory capacity.|
|2011-11-07 19:28:52, 7 years ago|
|Premium users have been moved to their own web forwarder today.|
I had moved the web forward system to a different provider 2 weeks ago - it seems that this provider has null routed the IP since yesterday, likely due to an attack.
I have been unable to reach them regarding this matter today. I am making adjustments to restore service to the free users this evening by rebuilding all the dns zones with some different IPs.
|2011-10-27 14:41:43, 7 years ago|
|ns1.afraid.org has moved from 18.104.22.168 to 22.214.171.124|
|2011-10-26 21:12:30, 7 years ago|
|Some code upgrades have been installed in the sync system today. The site now uses a log of journaled updates that can be replayed back from any time in history based on time, rather then tracking individual states of zones between servers.|
I believe this will improve the reliability of the sync system by allowing a server to be brought back into sync after maintenance, or network troubles more reliably. The way dns zones are built has also been re-implemented.
|2011-10-18 05:21:33, 7 years ago|
|ns2. will be offline while its previous configuration is restored. This process typically takes 2 to 4 hours.|
DNS will continue to function via the other DNS servers. This will restore 'Backup DNS' functionality.
|2011-10-17 09:45:40, 7 years ago|
|There has been some heavy DNS traffic today that has disrupted the flows of the service.|
I made some changes moved ns3. to a fresh IP, and initiated conversation with all network providers each server is on to see if they can enable any mitigation for the traffic flood.
NS1 CPU was exhausted - requested upstream filtering, not much luck this time
NS2 CPU was exhausted - was answering most of queries, though dropping many
NS3 Network was exhausted - high rate of packet loss at the network level
NS4 Network was exhausted - offline, null routed by provider
I decided to start building up a DNS instance with a static NSD config as an emergency solution, I had only tested it earlier this year. It took 40 minutes each time I tried to load the config - if any errors it would have to be started over. Took a bit of massaging to get it into a loadable state, but now this seems to be carrying things on NS2. I will continue work on the issue.
Update: NS4 has been restored by provider
Update: All zones have been rebuilt on the master and installed on NS2 - some zones that are not updated frequently were not installed initially.
|2011-10-17 06:22:28, 7 years ago|
|Seeing a lot of heavy traffic this AM.|
Moving ns3. to 126.96.36.199
|2011-06-13 15:11:21, 7 years ago|
|DNS servers have been receiving heavy amounts of traffic since 10AM PST|
ns4. has been moved to 188.8.131.52 to try and restore service - efforts to restore full functionality are still ongoing.
|2011-05-28 03:02:43, 7 years ago|
|ns2 has been put back into service with a replaced hard disk|
|2011-05-27 01:52:32, 7 years ago|
|ns2 just had a hard drive failure moments ago, and is rebooting its self.|
g_vfs_done():ad4s1f[READ(offset=147842723840, length=53248)]error = 5
vnode_pager_getpages: I/O read error
ad4: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=561213151
ad4: TIMEOUT - READ_DMA48 retrying (0 retries left) LBA=561213151
ad4: FAILURE - READ_DMA48 timed out LBA=561213151
Once a replacement disk is installed it will be returned to service, but will be unavailable meanwhile.
|2011-05-27 01:23:32, 7 years ago|
|ns4.afraid.org has been moved from 184.108.40.206 to 220.127.116.11|
|2011-05-11 12:50:48, 7 years ago|
|It looks like service to mooo.com has just been restored.|
As a reminder, it may take as long as 3 days to fully be restored across the entire internet, (172800 glue TTL + 86400 A TTL).
|2011-05-11 12:00:21, 7 years ago|
|Yesterday on Tuesday May 10th at around 11:15 AM PST mooo.com (the most popular shared domain at afraid.org) was suspended at the registrar level.|
There is no ETA at this time. Due to the way propagation works it will take 3 days for a restoration to take effect.
We are working to get the issue sorted as quickly as possible.
|2011-02-13 19:16:12, 8 years ago|
|It looks like service to mooo.com has just been restored.|
As a reminder, it may take as long as 3 days to fully be restored across the entire internet, (172800 glue TTL + 86400 A TTL).
|2011-02-12 07:07:07, 8 years ago|
|Last night on Friday February 11th at around 9:30 PM PST mooo.com (the most popular shared domain at afraid.org) was suspended at the registrar level.|
There is no ETA at this time. Due to the way propagation works it will take 3 days for a restoration to take effect.
freedns.afraid.org has never allowed this type of abuse of its DNS service.
We are working to get the issue sorted as quickly as possible.
|2010-12-12 01:40:10, 8 years ago|
|ns1 has been put back into service.|
|2010-12-11 21:05:47, 8 years ago|
|ns1.afraid.org has been disabled for maintenance, DNS continues to function via the other servers. ns1.afraid.org appears to have reached a OS memory limit, and started rejecting some updates to certain zones.|
In response to this, and also considering many zones are not valid that users have added, I am reducing the number of zones that must be loaded by disabling zones which have not passed the domain delegation health check a single time in the last 1 year.
This may be further reduced to a period of 90 consecutive days in the future, which is probably more reasonable.
|2010-07-16 15:03:46, 8 years ago|
|A user of afraid.org had a domain that around 7:30 AM PST came under attack, with many gigabits of malicious traffic at its peak directed to all afraid.org DNS servers. The attack is still in progress at the time of this writing, but has been reduced significantly.|
While attacks are not that unusual for afraid.org, they are generally not this large as today.
Unfortunately - this exhausted every ounce of resource available for afraid.org, and caused serious disruption for the site afraid.org, and for innocent bystanders sites that are also using afraid.org for their own sites.
So, after today's eventful morning, I will be taking further measures to protect users by increasing the available nameserver pool size from 4, to at minimum 64, and begin allocating configurations to members in a way that minimizes overlapping configurations as much as possible.
Over time I have observed that much of the human based problematic events such as this one comes from (a relatively small set of) unpaid members, it is a sad truth. I will not stop providing the free portion of the service, but I am strongly leaning toward moving paid members to their own tier of servers.
While afraid.org has not had a problem of this kind in a while, I'm going to reflect on this event and take measures to make the site better because of it.
|2010-07-16 09:11:42, 8 years ago|
|freedns.afraid.org is currently experiencing unexpected levels of traffic this AM|
|2010-05-12 12:26:32, 8 years ago|
|ns2.afraid.org is moving from 18.104.22.168 to 22.214.171.124 today|
|2010-03-22 01:00:20, 9 years ago|
|Tonight's maintenance has been completed - it was a continuation of events that started 3 weeks ago, had some unexpected bumps, after some flash upgrading, and card swaps this time it was successful.|
|2009-12-19 22:14:54, 9 years ago|
|The UI server suffered an unexpected interruption today, DNS continued to function via the alternate servers.|
I have placed an order for remote console access, so in the future it will be possible to access the server in times of network unavailability.
|2009-11-16 19:21:29, 9 years ago|
|ns4.afraid.org has moved from 126.96.36.199 to 188.8.131.52|
|2009-11-14 21:23:34, 9 years ago|
|A new database server has been added tonight. This should help reduce loads, and improve performance.|
How is it? Anyone notice?
|2009-10-06 19:43:31, 9 years ago|
|I have been thinking lately that a sincere thanks for those who have been supporting the site is in order. Premium memberships are the only thing which make it possible to get the equipment that is necessary to keep this project going, and maintained properly on a daily basis.|
If you are able to join as a premium member, please do. I will make the most of your support, and ensure your contributions are put to proper use! Your feedback is always welcome.
|2009-10-06 12:08:07, 9 years ago|
|In an effort to further add stability and diversity, an additional server will be added to the east coast soon.|
Servers distributed like so:
Los Angeles / Texas / Illinois / Washington DC
I will post an update when it becomes available.
|2009-09-12 14:17:18, 9 years ago|
|There was an interruption in DNS this AM, unexpected traffic levels were the cause.|
It appears a member of the site's domain came under heavy attack, and a malicious individual decided to attack the DNS servers, rather then the site its self.
The attack is still ongoing, the effects have been reduced with the help of one of afraid.org's upstream providers.
|2009-08-22 03:54:43, 9 years ago|
|I have been tweaking some settings on the server tonight in response to some non-typical traffic patterns. Still evaluating the changes, but I think things are in reasonably good shape now.|
|2009-07-26 20:21:26, 9 years ago|
|The stats page, and queries per second counter has been fixed, and retroactively backfilled.|
When the new backup servers were added, only a portion of the DNS traffic was being counted until now.
|2009-06-17 01:16:37, 9 years ago|
|ns2.afraid.org is online at 184.108.40.206|
|2009-06-16 00:42:39, 9 years ago|
|ns2.afraid.org is offline for the moment as it reached a software/OS based process size limit.|
I am in the process of retiring this machine. I will be bringing up a new ns2.afraid.org in its place, with a different IP shortly.
|2009-05-23 22:15:02, 9 years ago|
|ns3.afraid.org has moved to 220.127.116.11|
|2009-05-01 22:59:11, 9 years ago|
|A particular customer's domain was under attack tonight, unfortunately it reached the point of disrupting afraid.org's normal traffic.|
The customer has removed the domain, however possible filtering solutions for this are being researched.
|2009-03-18 18:49:01, 10 years ago|
|Looks like a fsck fixed the disk issue that was occurring, so there was no major problems.|
|2009-03-18 01:41:54, 10 years ago|
|The disk issue that is happening is that the primary disk is reporting more available space, then what could be possible.|
This could be an indicator of possible file system corruption, though there does not seem to be any operational problems aside from an inaccurate reading of available disk space. There are no SMART errors being reported.
This event was reported nearly immediately via health monitoring checks.
Worst case scenario, is re-installation of the operating system, and possible disk replacement.
Diagnostics are scheduled to be ran on the server.
Should have more news soon.
|2008-11-30 12:26:19, 10 years ago|
|ns3 has been upgraded to 2GB of RAM.|
This has greatly reduced its unresponsive durations while it reloads its DNS database.
|2008-10-10 22:10:34, 10 years ago|
|A new security certificate was added today, signed from a actual trusted certificate authority.|
This means no more pop up boxes and security warnings when visiting the site using SSL.
To use the site over SSL, the URL is:
|2008-07-16 10:16:53, 10 years ago|
|ns2.afraid.org has been upgraded from 1GB to 2GB of RAM.|
This has drastically improved its performance.
|2008-05-21 00:14:38, 10 years ago|
|The nightly backup system at 1:29AM PST each night for 10 to 20 minutes would cause a severe performance hit to the site, (yet perform a very important task).|
This method of backing up the site's database has been abandoned in favor of live offsite database replication.
The site will no longer have this routine interruption, as the slave server will always synced up any given moment to the second.
The international users of this service may especially appreciate this change. Though backups were performed early in the morning in the US, it is always peak time somewhere.
|2008-04-20 14:43:47, 10 years ago|
|A locking issue with the zone syncing system has been fixed.|
This issue was responsible for many "reload queue is full" error messages in the event of any one of the slave servers was running slow, or held up during a server reconfig which can take a few minutes.
The queue performance now shouldn't be impacted in any way whatsoever by the state of slave servers, (unlike before).
A future change / note to self might be to offload the queue to something that does not have such limited capacity and use message queues for event notification only. However right now if the queue is full (indicating > 30 users changes are pending) there is probably something going on that having a bigger queue won't fix given today's change, so we'll see how this does.
|2008-02-15 19:39:02, 11 years ago|
|A few hundred accounts got banned this morning unintentionally, they are unbanned now.|
My provider had started proxying my HTTP traffic due to an attack, and anyone who had any activity to their account started coming from the same IPs, which was triggering the ban system. I'll be whitelisting their IP space, as soon as they tell me their range.
I turned off the webserver until I could write a script to repair the database and clean out the ban triggers that had spread like wildfire to limit the damage.
A bit of a freak incident. There's been a couple this week.
|2008-02-13 10:01:38, 11 years ago|
|Yesterday a script with a socket error was writing to a log file very aggressively, this filled up the hard disk very quickly, and caused interruption to the web interface and URL redirection portion of the site.|
It was corrected later that evening when I had access to a laptop again. I apologize to those who were affected. It took about 2 minutes to fix.
|2008-02-05 19:22:36, 11 years ago|
|The domain broken checking should be back to normal. Some sort of a.root-servers.net anomoly, that only happens when using that particular root server, still not sure why, but the problem I experienced seems to be limited to a.root-servers.net only.|
|2008-02-04 10:40:17, 11 years ago|
|Most domains have fallen into a broken state for reasons that are not entirely known yet.|
The tool used to check domain authority stopped working, and also does not work from different servers, this indicates no one is blocking afraid.org's nightly bulk checks.
I'll see what I can figure out / find out about it.
|2007-12-25 09:10:43, 11 years ago|
|The primary server (web interface) had gone unresponsive around 5:30 AM CST from what I could gather through my providers traffic statistics.|
I put in a reboot request at 8 AM, once discovered, all daemons were running by 9:30 AM CST or so. The cause of the problem is yet to be determined.
|2007-11-17 17:11:45, 11 years ago|
|For users of the 'web forward' section:|
At approx 7AM PST the URL redirection IP was blackholed by my upstream provider, due to a network attack against afraid.org.
10 hours later (5PM PST) it is still blocked after my attempts over the last 2 hours to get it removed.
I'm going to force the URL redirection IP to be changed, this requires all zones to be re-generated, and re-loaded into the DNS software, this can take a bit to do. They should all be up shortly, one way or another.
Given today's incident and duration, it is clear this is not an adequate structure for the URL redirection.
Changing the IP of every URL redirect system wide on a moment's notice for everyone presents some challenges. The use of CNAMEs instead of A records as web forward destinations would be ideal. CNAMEs however, can cause conflicts with other record types in the same glue path (such as NS records) of which A records do not. I may begin using a combination of both.
I will continue to think on this problem, and see if I can work on a solution that will utilize all DNS servers for web forwarding in addition to just DNS and web interface access.
As with most of the inbound attacks, I generally don't get to know who, what, or why they occur. It very likely has nothing to do with me. I can only suspect someone upset someone else, and I got the cross-fire.
I will post a follow-up to this post. But that's today's news.
|2007-11-16 17:38:17, 11 years ago|
|Users may be able to notice an increased responsiveness to the website, and performance during the last couple of days.|
The average CPU load for the primary afraid.org server has been reduced to 30 to 40% of what it was.
Statistical analysis of traffic is being moved to a non-production server all together.
This is after 2 complete rewrites of this portion had been done in the past to accommodate ever increasing traffic.
|2007-10-19 15:45:19, 11 years ago|
|Memory upgrade success!|
real memory = 4227727360 (4031 MB)
avail memory = 4139905024 (3948 MB)
|2007-10-18 17:23:02, 11 years ago|
|Every once in a while, dynamic dns updates stop happening to a single zone.|
Users sometimes notice this and contact me, letting me know they have been waiting X hours for their IP change to show up.
When I hear about such a thing, I would often go through the logs, and see there are errors which the DNS server software is rejecting. I would then (by hand) go to the zone and find the line number, then go find the record in the database that causes the conflict, and remove it and force the zone to be re-generated.
Today a new daemon has been built which watches for any such errors automatically, and sends both me and the creator of the mal-formed record an email informing us both that any conflicting record has automatically been removed.
This will not only keep a zone functioning if somehow a malformed record makes it through the web interface, but also send me helpful diagnostic information to build a tighter system of error checking.
This was somewhat of a rare problem, but when it would happen to a zone like mooo.com which over 30,000 subdomains use, it has widespread affect on members who are unable to update their IP. This should now no longer be possible.
This sort of a setup is also going to be especially useful when allowing support for new record types.
|2007-10-17 17:08:11, 11 years ago|
|I'm in discussions with my provider to have the primary server upgraded from 2GB of RAM to 4GB of RAM. There will be a brief interruption of service to the web interface when this occurs... stay tuned.|
|2007-09-20 21:44:39, 11 years ago|
|MySQL has been upgraded from 5.0.37 to 5.0.45 tonight in response to some undesired behavior. Upgrade fixed it.|
|2007-04-24 06:34:51, 11 years ago|
|All servers were upgraded to the latest stable version of BIND 9.4.0 last week from 9.3.4.|
In the process, the query stats output has changed slightly (for the better). This change has been throwing my numbers (queries per second and DNS stats page) off for the last week, as it was not reading all the counters.
I've updated the stats scripts to accurately read the new values they added, and am re-parsing all of the old stats dumps, to repair the DNS stats section with accurate data for the past week.
|2007-04-22 23:21:27, 11 years ago|
|Nameservers now are no longer instantly reconfigured upon domain addition. This should have a substantial impact on the previous DNS timeout problem that would occur randomly throughout each day.|
While I much like the idea of providing instant zone additions, the reachability of the DNS servers is most paramount.
This should not impact IP changes/adds/updates, they will continue to occur in the order in which they are received (real time or near real time).
When a new zone/domain is added, a configuration reconfig must take place on the nameservers before a new zone can be served up. This process causes a nameserver to become unreachable for a short period of time while it analyzes its configuration for change.
This is still true, I cannot change how the DNS server its self is designed (though I understand much work is going into a threaded model that can answer queries while simultaneously updating its configuration, so I doubt this will be true forever).
As for now, this is a problem that has only increased with the growth of zones hosted. The problem translated into all sites receiving a DNS timeout when all nameservers do this at the same time. The problem was somewhat short, and random, but I'm sure several have noticed it, I know I have.
The add/delete a domain pages have been tuned for higher performance in the process of things, and the 'execute queue' button has been removed.
The domain additions/deletions should be fully propagated to all servers within 5 minutes at any given moment. Each nameserver will reload their configurations on their own staggered 5 minute interval (but never simultaneously, via a shared network lock, thereby preventing a total mini-blackout randomly throughout the day).
|2007-04-17 23:50:24, 11 years ago|
|The add a domain page has been tuned a bit.|
After some analysis and benchmarking, it was found that the domain namespace collision detection code specifically was the culprit for some unnecessary slowdown.
For example, this is the code that would prevent 'test.mooo.com' from being added as a domain, when mooo.com is already an existing domain, and vice versa.
Incase anyone might be interested, domains are now stored indexed in reverse, and each section of a domain 'com', 'mooo.com', 'test.mooo.com' is searched for as exact match, then searched on with a wildcard character.
Storing and searching for collisions in reverse (Example: 'moc.ooom.tset.*' vs '*.test.mooo.com') allows a great leverage of the database indexing capability, since domains/subdomains depth grows from the front.
Before this change, it was loading the entire list into an array, and performing a regular expression search inside of the application, for each and every time someone added a domain. There was a point in time where that was not a impactful method. Today I noticed a 100 MB httpd process and seen it was executing a domain addition, and that led to today's rewrite.
|2007-04-14 02:00:44, 11 years ago|
|The last day or two there has been an issue which surfaced. The DNS server software has grown in RAM consumption to manage to hit a single process RAM limit in the OS. The FreeBSD default per-process limit of 512MB has been bumped up to 1GB.|
Since raising this value, things seem to be performing better.
|2007-04-11 19:27:54, 11 years ago|
|Database server has been upgraded to the latest stable version.|
The site was disabled during the back-up process, prior to installing MySQL 5.0.37 from 4.0.20.
An attempt was made to do an initial sync off the live binary files to minimize downtime, however that seemed to load the server down to the point of being unresponsive anyways, so it made sense to shut down the web and database server all together, which made it go about 10x quicker.
|2007-02-26 21:43:07, 12 years ago|
|Server transfer has been completed.|
ns1.afraid.org has moved to -> 18.104.22.168
ns4.afraid.org has moved to -> 22.214.171.124
|2007-02-25 22:40:50, 12 years ago|
|The site will be transferred to a different server soon.|
The initial data syncs/testing phase has now begun.
Hope to cut over to the other new server within the next few days, or less.
Will post an update when completed.
|2007-02-20 20:29:52, 12 years ago|
|Some site stalling / database locking conditions have been alleviated by a rewrite to a set of internal statistical maintenance scripts.|
Web interface / update performance should be improved from last week, where some members may have experienced stalling, and timeouts.
|2007-02-20 15:38:45, 12 years ago|
|ns3. is back with a new hard drive and OS.|
|2007-02-19 11:16:44, 12 years ago|
|ns3.afraid.org has had a failing hard drive replaced in it.|
I'm working on rebuilding it now, it should be back soon.
|2007-01-31 15:45:58, 12 years ago|
|Latest OS/kernel snapshot is now running live on the primary server.|
|2007-01-31 10:51:46, 12 years ago|
|Hardware or OS?|
After the incident this morning (woke up to a load average of 200+), I am having thoughts about the issues with the server not necessarily being hardware related.
During the nightly backup (around 01:30 PST) the server ran out of disk space, however it was not showing it was out, which is *very* unusual, it was as if something in the OS was hanging it up.
The server is going to be brought down again to re-update the OS and kernel on it. We'll roll with that and see how it does. Its in the process of compiling the latest snapshot.
There is good news though, the ISP has recently agreed to do a chassis swap on the server just incase it is a actual hardware issue. I'm going to delay this route for now though, and see if a rebuild of the OS/kernel fixes these issues.
With these changes, this issue should be isolated soon.
|2007-01-23 03:06:29, 12 years ago|
|The diagnostics have been completed, nothing interesting was found.|
Still trying to sort the issue.
|2007-01-20 11:34:58, 12 years ago|
I have scheduled the diagnostics run, the site/server will be taken down beginning January 23rd 2007, (Tuesday morning) @ 1 AM CST for diagnostics by the server provider to attempt to locate the source of the crashing thats been happening every 2 weeks or so.
The expected downtime is roughly 4 hours.
|2007-01-01 09:48:12, 12 years ago|
I've been having some crashing issues with the server. (about once or twice a month). Going on for 3 months or so. Previous server never crashed, and it was much less powerful. I can't seem to re-create or induce it (but I also don't want to take the site down trying to break it either).
I'm working with the provider to try and get it resolved/diagnosed.
A simple reboot of the server takes about 1 hour to get all daemons and processes operating correctly at minimum.
It was taken down a few moments ago to setup some remote console/DRAC up on it to see if there are any further indications of the cause there.
Sometime in the future it will need to be taken down for some extensive tests, when this happens it will be done during the night time in the US which is the least busy time.
I've been trying to get a loaner server to minimize the outage/problems while this is figured out, but the provider is convinced its not a hardware issue currently, and I can't prove it otherwise, since no interesting log messages are written to the disk.
All the best... happy new year everybody.
|2006-12-05 00:55:25, 12 years ago|
|ns3.afraid.org has moved from 126.96.36.199 to 188.8.131.52|
|2006-10-15 16:35:38, 12 years ago|
|ns4.afraid.org has temporarily moved to 184.108.40.206 while some hardware issues are resolved.|
|2006-10-05 01:20:51, 12 years ago|
|ns2.afraid.org has moved to 220.127.116.11|
Please update your configurations accordingly.
|2006-09-30 03:55:26, 12 years ago|
|Databases have been moved to 2nd disk.|
|2006-09-30 02:46:15, 12 years ago|
|2 nights in a row the primary server has crashed.|
The hard disk is almost full, I'm going to try and free up some space, and move the databases to the 2nd SCSI disk.
It happened both nights at about the same time, during the nightly backup.
Even with a full disk, things shouldn't go down though.
The server is a leased rental, I am working with the provider on the issue.
|2006-07-05 23:39:14, 12 years ago|
|New server now live!|
The web interface, and URL redirections were interrupted during this cut-over / database sync transition.
I apologize for any inconvenience caused.
DNS itself suffered no interruption.
|2006-07-04 00:40:59, 12 years ago|
|New server has been ordered!|
Should be ready to go within the next week or two.
This will be replacing the current one, and therefore will be issued some new IP space, which should only impact those using DNS branding, whom I will email.
OLD] P4-3.2 GHz HT / 2 GB / 80 GB IDE hard disk
NEW] Dual Xeon 2.8 GHz / 2 GB / 2-SCSI 10k RPM drives
This should result in a web interface performance boost, now that I'll be able to offload some slow statistical analysis programs onto a 2nd hard disk (and SCSI to boot!).
Though it has a slower clock speed, it is a dual with larger caches, so the processing power will be signifigantly increased.
I'm also in the process of re-designing the nightly backup system which is the cause for about ~1 hour of more-then-necessary sluggish web interface performance that I've been getting a taste of first hand (oddly enough no one else has really mentioned noticing).
|2006-07-04 00:36:54, 12 years ago|
|The XML Programmer's API has been changed to support SHA-1 hashing, so plaintext passwords are no longer sent over HTTP|
The old plaintext method will still continue to work, however.
|2006-04-20 16:13:32, 12 years ago|
|There's been a IP change at freedns.afraid.org.|
Please update your DNS configurations/ACL's in accordance with
-> ns2.afraid.org is now 18.104.22.168 (AXFR's will come from here)
-> ns3.afraid.org is now 22.214.171.124
|2006-04-12 12:13:41, 12 years ago|
|The system no longer bans domains for 30 days upon deleting your own domain.|
Should a member re-add their domain to the system, their previous configuration will be restored.
This also makes it easy to move domains and their configurations to other accounts, the configurations will be restored in the new account.
|2006-03-27 19:09:51, 12 years ago|
|There's been an emergency IP change for ns2/ns3.afraid.org|
Please update your configurations accordingly.
ns2.afraid.org has address 126.96.36.199
ns3.afraid.org has address 188.8.131.52
These are temporary IPs while a server is in transit, and will change again in a couple of weeks or so.
|2006-03-14 14:54:46, 13 years ago|
|It is now possible for users to maintain their own blacklist of members to which they do not wish to share their domain with.|
This has been linked within the queue section of the site.
|2005-11-18 15:11:27, 13 years ago|
|Dynamic DNS updates will now also update other records pointing to the same IP address, so the use of CNAME records is not required, nor multiple HTTP requests to the web interface.|
|2005-07-16 11:27:25, 13 years ago|
|Moved from 184.108.40.206/29 to 220.127.116.11/29 |
If you have 18.104.22.168/29 in any of your old configurations, you can update them accordingly.
|2005-07-05 18:22:35, 13 years ago|
|If you lock yourself out via the ACL protection, the email it sends you will now also include a activation URL so that you may allow yourself back into your account, URL will be valid for 2 weeks, or until visited.|
This should also strip away any fear of using the ACL tool, since you cannot lock yourself out unless you fail to keep your email address current.
|2005-06-30 01:19:27, 13 years ago|
|New server has now gone live.|
The primary server has been upgraded from 2.4 GHz with 1 GB of memory to a 3.2 GHz HT with 2 GB of memory. Site was down for the move to a new physical server, DNS remained uninterrupted.
I'm currently syncing DNS changes once every 5 minutes to the old server until the IP change fully propigates.
|2005-03-31 21:43:24, 13 years ago|
|Email notifications now sent out when accounts protected with ACL protection have been breeched.|
|2005-03-31 21:17:04, 13 years ago|
|Support for SRV records has been added by request|
|2005-03-24 19:06:15, 13 years ago|
|ACL protection added|
This new feature allows you to specify your IP ranges so that no one but you can access your account in the event someone manages to get your password.
You can edit/maintain your ACL lists in the preferences section.
|2005-03-22 21:37:47, 13 years ago|
|http://freedns.afraid.org/safety/ is where I send malicious thieving traffic to. I re-wrote this document, and added some new stuff in an attempt to make it as informative as possible.|
It's also an all around good read if you are concerned about identity theft, so thought I would make it publicly accessable to help raise awareness here.
|2005-03-22 15:00:05, 13 years ago|
|New Feature: Support for Brandable Nameservers has been made public.|
|2005-02-25 19:16:06, 14 years ago|
|Account hostname limit behavior has been changed a bit.|
Due to abandoning the live NS authority check upon a domain addition, this opened up the ability for people to gain unlimited hostnames in their account by adding non-existent domains into their accounts.
As a result, the system has been changed to still allow 20 hostnames per domain, but the 20 hostnames are restricted to each individual domain. The 5 'free for all' hostnames can be used on existing domains, OR via the shared system.
More 'free for all' hostnames can be acquired by becoming a premium member, amongst other benefits!
|2005-02-17 17:36:07, 14 years ago|
|DynDNS clients now supported|
I've been seeing strange updates in my webserver logs, so I tried to adapt to them as best as I could.
BASIC support for 'dyndns' updates is now added and functional
|2005-02-17 12:22:04, 14 years ago|
|ISP will be performing maintence where primary server is located.|
Should an outage happen during this time, alternate slaves will continue to operate and function should the web interface to afraid.org become unreachable.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Global Network Maintenance - Monday 2/21/2005 01:00 am CST (UTC -0600)
Planet Engineering will be conducting maintenance on a TippingPoint Intrusion Prevention module beginning at 01:00 am CST (UTC -0600) on Monday, 2/21/2005 and
lasting until 03:00 am CST (UTC -0600) the same day.
We do not anticipate any extended downtime. However, because fiber connections are being moved, customers may experience intermittent packet loss or
increased latency for a brief period of time. Planet Engineering will do everything possible to prevent a loss of connectivity.
This work is applicable to Planet Bandwidth customers only. MatriXtreme customers (unmetered Cogent-only network) will NOT be affected by this work.
Planet Engineering and Security Teams
|2005-01-11 17:14:00, 14 years ago|
|In preperation for the electrical maintence being performed tonight at midnight by my ISP, ns2.afraid.org has been moved to an alternative server so that it won't be impacted.|
|2004-12-31 17:34:24, 14 years ago|
|Backend system has been rewritten.|
Configuration changes are handled much more intellgently now, this will reduce load on the server, and increase response time.
This also allows users to mass-add domains without creating undo stress on the server with the new ability to load changes into the nameserver when they're done.
Those who don't use CNAME's and do mass dynamic updates are also reduced/consolidated, the queueing system is shared, so if 2 people add domains at the same time, and 1 executes the queue, the other person when they execute the queue will not do the same redundant task.
|2004-12-19 16:12:36, 14 years ago|
|Moved site back to original server after working it hard, unable to cause it to crash. Server seems solid.|
Found other provider to not be well suited for my needs, I will instead use them for secondary services.
|2004-12-13 20:31:28, 14 years ago|
|Site and content have been moved, due to repeated connectivity/outage problems with last server.|
I am uncertain if it's hardware related, or their filtering mechanisms falsely kicking in, so I've decided to make the move, and once all traffic is shifted over, do more extensive testing.
|2004-07-12 03:40:14, 14 years ago|
|Upgraded from BIND8 to BIND9.|
2 benefits from this are:
FreeDNS can now support Microsoft Caller ID records, a newly emerging technology of blocking spam.
FreeDNS can now ignore the TTL cache period when adding domains. Independent process for handing DNS authority checks. (Highly requested).
|2004-05-16 23:58:39, 14 years ago|
|For anyone having trouble recently with CNAME's not resolving, this problem has been fixed.|
Due to the transition phase of moving to the new ISP, their temporary server ran out of inodes on /, which required me to move all DNS data to another partition on the server with more room.
In this process, the path pointing to the root hints file was not updated properly, causing glue problems of CNAME to A records.
I apologize for any inconvenience.
|2004-04-03 02:14:30, 14 years ago|
|Made IPv6 Reverse section live.|
|2004-03-05 02:27:38, 15 years ago|
|New 2.8 GHz server with 1 GB of RAM is now online.|
Have sync'd databases over from the temporary loaner server my new ISP, National Net, was generous enough to loan to me to avoid downtime.
Load average is much lower, and server is much more responsive. DNS queries per second has also increased, normally around 120 has been doing between 300 or 500 since the switch, which... I had not expected. Inbound throughput is the same, but outbound is quite a bit higher with the increased queries per second, which I can only attribute to the increased CPU power.
|2004-01-19 01:40:32, 15 years ago|
|Glad to say Afraid.org has been upgraded with fault tolerant mirrored RAID disks. ns2.afraid.org carried the load of the DNS traffic while the main server was down for upgrades which was about 4 hours.|
I've had to re-install the operating system, please let me know if you see any oddness with the site, I think most of the kinks are worked out. :)
BTW it's a 3 hour drive between my house, and the server in Fremont, CA, and I didn't have a good chance to thoroughly check things out until I got home. I was on the road for 6 hours today.
|2003-10-04 20:31:24, 15 years ago|
|Server was down for a short while today while I installed more RAM into the server.|
|2003-06-03 01:16:09, 15 years ago|
|PHP upgraded to 4.3.2|
MySQL upgraded to 4.0.13
No problems encountered
|2003-05-31 01:53:13, 15 years ago|
|Speaking of reading the webserver logs... there is a awful lot of dynamic DNS updates being issued to the server, let me just say a couple things.|
1) If you have 8 hostnames, you don't have to update 8 hosts. All you need to do, is update 1 host, and make all the other hosts you want to be updated CNAME records to the hostname you are updateing. Also keep in mind, you can use CNAME's with any hostname on the Internet, so if you have multiple dynamic dns accounts with other providers, and you are updating your IP there, you don't even have to make updates to freedns, you can make all your hostnames CNAME's to that host.
2) Some people are writing their own update scripts and running them once a minute, not only that but doing it for multiple hosts and updating each host. If you download and install php from www.php.net as a command line tool (./configure && make && make install), you may find this script useful. You are free to write your own, but that checks if your IP has changed every 5 seconds, and makes a single update to the server only when the IP changes.
I would appreciate updates not being made once a minute, but instead only making updates when necessary ideally. It's not really a problem right now, but I don't ever want it to be either :)
|2003-05-31 01:38:42, 15 years ago|
|Added mod_gzip to freedns.afraid.org today, so now the 'add/edit a subdomain page' should load faster, I was noticing my logs saying that page was 110k, and it just seemed sluggish overall, and is one of the most regularly accessed pages.|
After installing mod_gzip it shows up at about 26k in the logs now, and seems to load faster from here. ASCII text compresses very well, the domain registry page which was about 1.2 MB in size comes down the wire using about 78 KB of bandwidth, which on my home connection loads signifigantly faster, so instead of having it broken up over multiple pages I have made it 1 large list again, which makes it easy to find a domain by using CTRL+F, instead of searching through the drop down box.
|2003-04-22 19:43:05, 15 years ago|
My ISP only charged me for bandwidth at cost, which was $470 last month, things could have been much worse. They gave me a break from what I would have owed according to my contract with them.
Hopefully I will have a more long term anti-ddos setup in place in the near future, when my ISP allows their customers to block their own IPs it should be pretty sweet.
|2003-04-15 11:44:18, 15 years ago|
$3200 worth of bandwidth, in a day.
I was moving into my new house yesterday, so didn't catch the network usage until today since I don't have Internet at my new house yet.
I'm in the process of trying to get the bandwidth charges dropped...
|2003-03-12 19:58:11, 16 years ago|
|Afraid.org was down due to a power supply failure. I called my ISP when I noticed the server down, they said there was an error on the screen about a low mbuf setting, and the server wasn't responding to keyboard input, they then rebooted it to see if they could get to a login prompt, and they got the same message, they then booted it into single user mode, and did get it to a prompt, but Afraid.org wouldn't respond to keyboard input they said, they then rebooted it again and it would not power on at all.|
I'm 2000 miles away, so I had to hire them to fix it, they were very speedy in getting it back up once they received the signed work order, glad to report things appear to be back and running ok. Sorry for the outage, but glad it was an easy fix ($125/hr).
|2003-01-05 15:19:36, 16 years ago|
|FreeBSD OS upgraded from 4.2 to the latest 4.7 today. I was dreading doing this remotely since I do not have remote serial console access to the server should something go wrong, but I wanted to do traffic shaping which required a new kernel. I am pleased to say the upgrade went extremely smooth with no problems! :) My last FreeBSD 4.2 installation was over a year old.|
In light of the recent DDoS attacks I wanted the ability to limit how much data could reach actual services, in one of the recent attacks that I did not publish, the load average went through the roof on the server (40+), and lag was so bad that I could not even see what IP was getting attacked, or what "run away" program was bringing the system to a grinding halt. Now with traffic shaping installed, the kernel will drop excessive traffic and not even try to have any applications process it.
|2002-12-31 16:52:29, 16 years ago|
|Another DDoS happened just now...|
Only 8 hours from the last one.
The night crew at my ISP seems to be faster to respond. I pay for bandwidth on the 95th percentile, so it would take 36 hours of flooding (combined throughout the month) to effect my bandwidth cost.
|2002-12-31 08:31:51, 16 years ago|
|Another DDoS today...|
Seems to be a regular thing now. Good news is they're getting easier to stop.
Service should have been mostly uneffected.
|2002-12-28 21:08:27, 16 years ago|
|Yet another DDoS attack, just a few moments ago. I phoned my ISP and asked them to block the old IP ns1.afraid.org was on, the attack however was also aimed at ns2.afraid.org.|
ns3.afraid.org and ns4.afraid.org aren't being attacked, which makes me think instead of an IRC user, someone is trying to get someone's domain shut down within freedns? Perhaps someone who hasn't updated their domain with ns3.afraid.org and ns4.afraid.org records has ticked someone off using their domain hosted in freedns. This time however afraid.org has had no down time.
I'm ready for IPv6 to come out... this is so lame... I wonder if the attacker is reading this... the type of attack is a distributed attack, from maybe hundreds of zombie computers that the attacker has control over. When the attack bots are instructed to they will flood a network link with garbage traffic. The problem, is many ISP's on the Internet don't have their routers configured to stop IP spoofing from their networks, on these particular ISP's a user can send traffic out without using a real IP address for the return packet, and their router passes it to the public internet.
If ISP's made sure users couldn't spoof from fake networks these type of attacks would be easy to track down. IPv6 should fix this by default. It could be fixed with IPv4 but due to clueless admins being able to attach their networks to the public Internet, not much can be done from my side. My best defense is moving public dns traffic to another IP address.
|2002-12-27 03:14:31, 16 years ago|
|Another DDoS today. I phoned my ISP and asked them to block ns1.afraid.org from the Internet. Static FreeDNS IP users should have been uneffected however those with dynamic addresses were unable to make updates for about 6 hours. The server was blocked within 15 minutes of the attack. I was told it would automatically be unblocked after a period of time, but it wasn't, I apologize for the lengthy outage, when I phoned in a 2nd time they had me unblocked within 15 minutes.|
Also today an ns4.afraid.org has been brought online, thanks to Ben Kerensa for offering to supply the server and bandwidth for this. I would like to encourage everyone to update their domains to support ns3.afraid.org and ns4.afraid.org which have both recently been brought online. ns3.afraid.org which has been operational for a few weeks now is generously being hosted by Donald Williams.
Since DDoS attacks seem to not be stopping (and I am assuming the source of this attack isn't even a FreeDNS user but maybe a direct result of someone trying to attack another freedns user and thinking I am an ISP) I am looking for ways to keep the website up through an attack. I'm going to move public services to another host and see if the attacks follow it. I'm also considering setting up pass through cache servers to protect the real server, but I have to determine if this attack is aimed directly at me or not, time will tell.
|2002-12-10 17:39:22, 16 years ago|
|4 day ns1.afraid.org outage, and 330 day all time high uptime lost...|
Well ns1.afraid.org was packeted with 700 megabit of traffic this last weekend, which resulted in my IP and subnet being blocked off in multiple places by my ISP and one of their ISP's, the attack was large enough for them to notice, it basically took 4 days, multiple telephone calls, and multiple emails to un-block ns1.afraid.org from the Internet because no one could login to my server from the console to find out why it still wasn't online even after they thought they un-blocked me in their routers, I guess my keyboard port on ns1.afraid.org no longer works according to the tech, so that made it incresingly difficult to resolve the situation, and ns1.afraid.org almost got de-racked and looked at by a hardware tech. Fortunately they found the additional null routes in their routers and I can get to my server once again.
This is the first time I have had to rely on ns2.afraid.org to actually carry the load of the DNS traffic, initially ns2.afraid.org was mis-configured, and with Allen's help at spysatcentral.net who is hosting ns2.afraid.org I was able to get it functioning to serve DNS with the last transferred zone files from ns1.afraid.org while ns1.afraid.org was unreachable for the last few days.
What I have really been wondering, is Why on earth would someone packet this server? Who did I upset? Due to the way the Internet works (a public network we all share) it is impossible to block these types of attacks when they originate from comprimised machines from all over the Internet. Fortunately though the worst that packeting can do to a system is make a system unreachable for a period of time, but with the communication issues I had with my ISP, the downtime was a bit longer the I hoped for. I don't know if the attack was directed at me, or directed at someone who was using an afraid.org hostname. DNS traffic on afraid.org consumes a (comparitively) very small amount of traffic, and could get by with having the server on a cable modem but it wouldn't be as responsive to dns requests, and subject to outages much more regularly, I chose to put the server in a nice 100 megabit burstable facility instead, for better response times and rock solid power protection.
Well thats all the news I have, sorry for the outage, it was totally out of the blue but I can't stop my ISP from turning me off when my server uses a volume bandwidth they don't expect me to pay for. At least I didn't get stuck with a huge bandwidth bill like some other ISP's would probably try to do. The folks at he.net are great.
|2002-11-22 08:29:28, 16 years ago|
|Sponsor count is updated immediately now on the site. I have been incrementing/deincrementing the sponsor count by hand up until now, there have been 82 subscriptions to FreeDNS and 29 cancelations to net 53 current subscribers I had 56 in there so my count had gotten off somehow.|
The moment someone makes a subscription the sponsor count should immediately update. Same goes for if someone cancels the donation subscription.
Thank you subscribers for doing what you can to keep the service alive. Last month FreeDNS's combined donation income was $146! I am very pleased to say FreeDNS is getting close to having it's financial goals met. Great work guys!
|2002-10-26 16:48:04, 16 years ago|
|For those of you who don't follow the forums area in FreeDNS there has been a few recent changes to the service|
* Multiple MX support - You can now set your MX to something like host1.afraid.org,host2.afraid.org (no spaces) and priority on the MX will be set in the order you enter the hosts, if you don't know what this means it probably doesn't effect you.
* Shortened TTL - Your ISP's cache should drop any old entries you used to use in FreeDNS within 60 seconds of your address change to a record in FreeDNS.
* Pending status removed - If you add a domain, it will instantly be accepted into the system and fully functional
|2002-10-15 21:28:49, 16 years ago|
From 12 noon to 9:00 pm PST it looks like afraid.org's was unreachable to the Internet due to my provider being down, things seem to be operating correctly now.
|2002-04-16 01:36:13, 16 years ago|
|Fixed a bug that was causing certain domains not to update do to mal-formed mutilated records in the zones breaking all records within a zone.|
|2002-03-09 22:56:56, 17 years ago|
|Made secondary DNS and dynamic DNS areas live and visible to all.|
|2002-03-06 20:04:51, 17 years ago|
|Added IPv6 (AAAA) support|
|2002-03-01 21:35:20, 17 years ago|
|MySQL upgraded to 3.23.49, site was down for about 30 mins for the upgrade.|
|2002-02-28 21:42:19, 17 years ago|
|PHP upgraded to 4.1.2 on the server as per the advisory at security.e-matters.de. Upgrade had no problems.|
|2002-02-26 17:45:03, 17 years ago|
|Many of the accounts in FreeDNS are not regularly logged into. In the last day, there have only been 32 users who have logged in, and of these 32 users, 2 have made a contribution. Thanks to these 2 users, 7% of the hosting costs for FreeDNS have already been eliminated, I hope this encourages those who have not donated yet. If you find this service useful, please make a contribution. There is great power in numbers that choose to stand together!|
|2002-02-26 01:21:57, 17 years ago|
|FreeDNS needs your help! Please check out what's happening with FreeDNS.|
|2002-02-24 21:33:04, 17 years ago|
|I was doing some reading tonight and found out that for me to become a REGISTRAR to allow domain registrations in FreeDNS it would cost $2,500 USD for the application and $4,000 USD a year, and an additional $500 per TLD per year. It's too bad that I can't afford to do this because I would really like to. If they don't slap on an additional fee per domain registration, and I could get the financial backing to do this by anyone, I would be willing to give away free domain names. If anyone is interested in funding this project, let me know!|
|2002-02-22 11:31:02, 17 years ago|
|I've updated the Sign-Up FAQ (Not linked inside the members area) that some of you may also find useful, it also tells a little bit about Afraid.org and it's background Click Here|
|2002-02-22 03:24:58, 17 years ago|
|The problem with subdomains with periods in them not being able to be NS or CNAME or have MX records has been identified and fixed. NS records take all authority for a subdomain so instead of leaving this feature disabled, a check has been put in place so conflicts no longer happen and service can continue as normal.|
|2002-02-22 03:07:52, 17 years ago|
|A new feature has been added by request of a user, the feature can be found for domain owners, if you click on Edit SOA you'll notice an AXFR checkbox, if that is checked (off by default) hosts anywhere on the Internet can transfer your entire zone file and all the hosts in it to their systems.|
|2002-02-22 02:53:36, 17 years ago|
|I'm pleased to say that the load average on afraid.org is at an all time low. I'm sure many of you have noticed a signifigant speed increase with the new FreeDNS interface.|
If any of you have any ideas for a feature that you would like to see in FreeDNS let me know.
|2002-02-20 17:16:19, 17 years ago|
|New version of FreeDNS made live!|
Lots of changes and security fixes, I would like to hear any comments/suggestions about the new layout that you might have, feel free to contact me.
|2002-02-19 20:56:03, 17 years ago|
|NS2.AFRAID.ORG is now properly working!|
Somehow the IP address for NS2.AFRAID.ORG got switched at the registrar and when I tried to move it back the secondary nameserver that has been donated to afraid.org had already been setup as a nameserver for another domain so NS2.AFRAID.ORG is now on it's own IP address on that server hosted at a totally seperate place then NS1.AFRAID.ORG (they're 1800 miles apart).
|2002-02-06 11:50:38, 17 years ago|
|Added support for Secondary DNS!|
Users may now add their domains into the secondary DNS section for JUST secondary DNS hosting.
|2002-02-04 05:03:45, 17 years ago|
|Added Dynamic DNS!|
Users may now update their IP address to their current IP address by fetching a single URL. Useful to put into a re-connect script.
|2002-02-04 05:02:31, 17 years ago|
|Added URL Redirecting!|
Users may now redirect any subdomain.domain.com to any URL of their choice.
|2002-02-04 00:43:35, 17 years ago|
|Added support for Round Robin DNS!|
Users may create multiple records with the same hostname to take advantage of this feature.
|2002-01-29 11:52:08, 17 years ago|
|Added a NEWS section!|