Change a destination

Know what counts as a change

The destination record holds two fields, an IP address plus a UDP port. Editing either one counts as an address change. The replacement pair must prove customer control through a fresh challenge.

Each destination permits ${ADDRESS_CHANGES_PER_DAY} address changes per day. No published rule covers its time zone, reset boundary, remaining-change display, or treatment of a no-op save. Preserve the allowance by saving only prepared pairs, and treat the dashboard result as authoritative.

The paid slot remains one destination. A change does not create documented parallel fanout to the old and new pairs.

Prepare the new path before saving

Build and test the customer-controlled path first. Every challenge and stream datagram comes from ${SOURCE_IP}. Add that source to the new firewall path before requesting verification.

1. Allocate a public IP together with the new UDP port.
2. Bind the new receiver to its local UDP port.
3. Add a static UDP mapping when NAT is present.
4. Allow ${SOURCE_IP}/32 at the new edge firewall.
5. Allow ${SOURCE_IP}/32 at the new host firewall.
6. At the replacement receiver, start a capture restricted to ${SOURCE_IP}.
7. Record the old destination pair and state.

Use a local test packet only to confirm the receiver binding and internal path. It cannot replace the provider challenge because proof requires receiving the service datagram from ${SOURCE_IP} at the configured public pair.

Save and verify the new pair

1. Select the existing destination through the dashboard.
2. Replace its IP field with the new public address.
3. Replace its port field with the new UDP value.
4. Save these edits as the next pair.
5. Issue its verification challenge.
6. On the replacement receiver, read the arriving token.
7. Fill the dashboard proof field with this value.
8. Submit before ${CHALLENGE_TTL_SECONDS} seconds pass.
9. Leave the replacement receiver open.

At the front of the challenge is SHREDCAST-VERIFY. Its destination ID appears next, followed by the token. No exact delimiter is published. One request sends one datagram. If loss or expiry occurs, request fresh proof.

Do not paste a token captured on the old receiver or from an earlier request. The new challenge proves control of the changed pair.

Confirm new delivery

Replace 9000 with the new destination port and run on the new host:

sudo tcpdump -n -i any -c 20 'src host 203.23.178.228 and udp dst port 9000'

Confirm that the application counter advances over the same interval. A capture proves that the host sees packets, while the application counter proves that the socket path accepts them.

The exact activation delay after re-verification is not currently specified. Record UTC times for token acceptance, first captured stream packet, and first application packet instead of assuming a threshold.

Retire the old customer path

Remove old firewall and NAT entries only after confirming the new path. Retire the former receiver under your own change policy. These customer-side actions neither create nor delete a provider destination.

The contract defines no parallel delivery, no free rollback to the prior pair, and no transactional cutover. Unless the dashboard states otherwise, returning to the former pair is another counted address edit requiring proof.

Keep the old configuration record with UTC timestamps long enough to investigate a cutover incident under your own retention policy. A required record-retention period is not currently specified.

Handle NAT port changes

The public destination port and internal receiver port can differ under NAT. Changing only the internal mapping while leaving the registered public pair unchanged is a customer network change, not necessarily a dashboard address change. It still can interrupt delivery.

When the public port changes, update the dashboard and complete verification. When only the internal port changes, update the NAT rule and host firewall together, then confirm capture and application counts. Whether the dashboard treats any specific edit as a counted change is authoritative in the interface.

Avoid consuming the change cap

Do not use destination edits to test whether a port is open. Bind the socket, inspect firewall policy, and validate internal routing before saving the new pair. Use one planned dashboard change for one prepared migration.

Do not alternate between old and new addresses while diagnosing. Each save can require another challenge and can consume the daily allowance. Preserve the last verified working pair when further changes are blocked.

If the dashboard reports the daily cap, wait until it permits another change. An override, increased limit, exact reset time, and support exception are not currently specified.

Plan a production migration

Choose a change window that permits observation of both network edges. Assign one operator to the dashboard and one to receiver telemetry when staffing allows. Record destination ID, old pair, new pair, requested challenge time, accepted token time, first packet time, and counter deltas.

This operating method is a customer recommendation. No maintenance-window scheduler, migration API, webhook, or status callback appears in the product definition.

Account for raw UDP behavior during the cutover. There is no ordering, retransmission, or backpressure. Packets sent to a closed or blocked path cannot be requested again from the transport.

Diagnose a failed change

If no challenge reaches tcpdump, verify that the saved public pair is correct and every new layer allows ${SOURCE_IP}. When only tcpdump records the challenge, inspect the bind address, local firewall, and network namespace.

If the dashboard rejects the token, request a fresh challenge and submit its current token within ${CHALLENGE_TTL_SECONDS} seconds. If verification succeeds but the stream is absent, compare the dashboard pair with the capture filter and receiver binding.