TFHost Incident Recovery Analysis

Date: 2026-05-26 Timezone: KST (UTC+9) Observer Location: South Korea (KT ISP) Resolver Used: Cloudflare DNS (1.1.1.1)

Executive Summary

A provider-level outage affected TFHost’s DNS authority (tfhost.ng) and customer VPS network reachability.

Real-time telemetry logs show:

• DNS authority failure (SERVFAIL)
• Temporary resolver communication timeouts
• SSH port (22/tcp) persistently unreachable
• Sudden simultaneous DNS and SSH recovery
• Stable recovery confirmed afterward

This evidence suggests that the outage was not caused by a single VPS daemon failure, but by a broader provider-side infrastructure incident involving the TFHost control plane and associated network path.

Observed Systems

TFHost Control Plane

Host:

tfhost.ng

Observed normal A record after recovery:

160.119.196.25

Customer VPS

Host:

oborona.zip

Resolved A record:

160.119.197.71

Observed service:

SSH (22/tcp)

Recovery Monitoring Method

Automated monitoring script executed every 30 seconds:

Checks:

1. DNS resolution of tfhost.ng through Cloudflare (1.1.1.1)
2. TCP connection to VPS (160.119.197.71:22)

State logging:

• DNS state
• SSH state
• Event changes
• Full recovery detection

Real-Time Recovery Timeline

Initial Failure

At monitoring start:

2026-05-26 19:38:42 KST
DNS=SERVFAIL
SSH=DOWN

Meaning:

• Public resolver (1.1.1.1) reachable
• TFHost authoritative DNS not functioning
• VPS SSH unavailable

DNS Communication Flapping

Observed intermittently:

DNS=;; communications error to 1.1.1.1#53: timed out
;; no servers could be reached

Important correction:

This does not mean TFHost returned that response.

It means:

• The monitoring probe itself temporarily failed to receive a DNS response from Cloudflare (1.1.1.1)
• Possible transient path instability, packet loss, or timeout during incident conditions

This is distinct from:

DNS=SERVFAIL

Which means:

• Cloudflare resolver answered
• TFHost authoritative delegation still failed

Therefore:

Two different DNS failure states were observed:

Persistent SSH Failure

Throughout the flap:

SSH=DOWN

Observed continuously from:

19:38:42
→
19:45:14

Meaning:

• VPS host (160.119.197.71) remained unreachable
• Control plane instability had not yet translated into compute recovery

Simultaneous Recovery Event

At:

2026-05-26 19:45:49 KST

Monitoring log:

DNS=160.119.196.25 SSH=OPEN
EVENT DNS_CHANGED old=SERVFAIL new=160.119.196.25
EVENT SSH_CHANGED old=DOWN new=OPEN
EVENT FULL_RECOVERY

Meaning:

• TFHost control plane DNS returned a valid A record
• VPS SSH (160.119.197.71:22) became reachable
• Both control plane and customer network path recovered simultaneously

Recovery Persistence

Subsequent checks:

2026-05-26 19:46:21 KST
DNS=160.119.196.25 SSH=OPEN
EVENT FULL_RECOVERY

2026-05-26 19:46:52 KST
DNS=160.119.196.25 SSH=OPEN
EVENT FULL_RECOVERY

Manual validation:

$ dig @1.1.1.1 tfhost.ng

Returned:

status: NOERROR
tfhost.ng. IN A 160.119.196.25
Query time: 4 msec

At:

2026-05-26 19:47:10 KST

Technical Interpretation

Actual Logical Relationship

DNS Resolution Path

Local PC
→ KT ISP
→ Cloudflare (1.1.1.1)
→ TFHost authoritative nameservers
→ tfhost.ng resolves to 160.119.196.25

VPS Service Path

Local PC
→ KT ISP
→ global transit network
→ TFHost routed prefix
→ VPS 160.119.197.71
→ SSH 22/tcp

Why Simultaneous Recovery Matters

The recovery event showed:

DNS restored
AND
SSH restored
at the same timestamp

This strongly suggests:

• Provider-side control plane stabilization
• Network/routing plane stabilization
• Not merely a DNS daemon restart

Because if only DNS recovered:

DNS OK
SSH DOWN

would have occurred.

That was not observed.

Recovery Window

Monitoring start:

19:38:42 KST

Full recovery detected:

19:45:49 KST

Total monitored outage window:

7 minutes 7 seconds

Incident Pattern Summary

Observed progression:

1. DNS authority failure (SERVFAIL)
2. DNS query-path timeouts
3. Persistent VPS SSH failure
4. Continued DNS flap
5. Sudden simultaneous DNS + SSH recovery
6. Stable recovery validation

Final Assessment

This incident is consistent with:

Provider-level infrastructure flap

Most likely involving one or more of:

• Authoritative DNS instability
• Control plane outage
• Routing/prefix instability
• Network recovery synchronization

Key Evidence

Outage Start

2026-05-26 19:38:42 KST
DNS=SERVFAIL
SSH=DOWN

Recovery Event

2026-05-26 19:45:49 KST
DNS=160.119.196.25
SSH=OPEN
EVENT FULL_RECOVERY

Manual Validation

2026-05-26 19:47:10 KST
status: NOERROR
tfhost.ng IN A 160.119.196.25
Query time: 4 msec

Conclusion

TFHost experienced a provider-side outage affecting both:

• DNS authority
• Customer VPS network reachability

Recovery was observed as a simultaneous restoration of:

• Public DNS resolution
• VPS SSH connectivity

This strongly indicates infrastructure-level recovery rather than isolated application recovery.