Sujet : networking
-
Modifier un enregistrement DNS avec un plan de retour arrière : abaissement du TTL, bascule et vérification
Une modification DNS n'atteint les utilisateurs qu'à mesure que l'ancien TTL expire dans les caches : il faut donc abaisser le TTL une durée complète de l'ancien TTL avant le changement, laisser l'ancienne cible en service jusqu'à confirmation de la nouvelle partout, et tenir compte des résolveurs qui, comme le permet la RFC 8767, continuent de servir des données périmées lorsque les serveurs faisant autorité sont injoignables.
-
The TLS 1.3 handshake in outline
TLS 1.3 negotiates keys in one round trip: the ClientHello already carries a key share, the ServerHello answers with its own, and everything after it, including the certificate, is encrypted. Resumption uses pre-shared keys from session tickets; 0-RTT early data is optional and replayable.
-
MTU, fragmentation and path MTU discovery
Ethernet carries 1500-byte IP packets, tunnels and PPPoE carry less, and IPv6 routers never fragment. Path MTU discovery depends on ICMP Packet Too Big messages; when those are filtered, large packets vanish silently while small ones pass, the classic black hole that MSS clamping or packetization-layer probing works around.
-
DNS records a web service depends on
A, AAAA and CNAME map names to addresses, MX routes mail, TXT carries verifications and policies, CAA restricts certificate issuers, NS delegates zones; check authoritative answers, not only a cached resolver, before and after changes.
-
Measuring home internet throughput repeatably: a fixed-path, fixed-schedule protocol
A proposed protocol for a household throughput and latency series: hold the device, the wired or wireless path, the test tool and the server constant, run three consecutive tests in three fixed daily slots for two weeks, log connection count and household activity with each run, and read RFC 6349's bandwidth-delay product and single-versus-multiple-connection points as reasons why tool settings change the number; nothing is claimed about any provider.
-
HTTP/1.1, HTTP/2 and HTTP/3: the differences an operator notices
HTTP/1.1 sends one request at a time per TCP connection in text framing; HTTP/2 multiplexes binary streams over one TLS connection with HPACK compression but still stalls on TCP loss; HTTP/3 runs over QUIC on UDP, removes transport head-of-line blocking and is discovered through Alt-Svc or HTTPS DNS records.
-
SSH tunnels: local, remote and dynamic port forwarding
ssh -L exposes a remote service on a local port, -R exposes a local service on the remote host, -D provides a SOCKS proxy and -J hops through a bastion; combine them with -N, bind to localhost and set ExitOnForwardFailure so that a forward that could not be set up does not leave a silently useless session.
-
How long did clients keep using the old address after a DNS change, and which resolvers or clients ignored the TTL?
Open question: RFC 1035 defines the TTL as the interval a record may be cached before the source is consulted again, and RFC 8767 lets resolvers serve stale data when authoritative servers are unreachable; after a real record change with a lowered TTL, how long did traffic to the old address persist, and which resolvers, libraries or long-lived processes were responsible for the tail?
-
Tries for prefix lookups: autocomplete and longest-prefix matching
A trie stores strings with one node per common prefix, so lookup costs the key length regardless of how many keys exist, all keys with a prefix form one subtree, and the longest stored prefix of a query is found in one walk; use it for autocomplete and routing, and compare against a sorted array first.
-
Timeouts, retries and backoff with jitter
Every remote call needs a timeout; retries must be bounded, applied only to idempotent or key-protected operations, and spaced with exponential backoff plus jitter to avoid synchronised retry storms.
-
A minimal nftables ruleset for a single server
One inet table with an input chain that drops by default, accepts established and related traffic, loopback, the ICMP types the stack needs and the listed service ports; checked with nft -c -f before loading and loaded with a timed rollback so a mistake cannot lock you out.
-
HTTP keep-alive and connection reuse: pools, idle timeouts and the stale-connection race
HTTP/1.1 keeps a connection open for further requests unless a Connection: close is sent, which removes a TCP and TLS handshake from every request after the first; the client must keep a pool for the life of the process, read every response body, and set its idle timeout below the server's so it does not reuse a connection the server has already closed.
-
NAT: how address translation works and why inbound connections fail
A NAT rewrites the source address and port of outgoing packets and keeps a mapping so replies can be routed back; nothing routes an unsolicited inbound packet to a private host. Mappings expire when idle, hole punching works only for certain NAT behaviours, and carrier-grade NAT adds a second layer the subscriber cannot configure.
-
A home network device inventory: an observation table behind every row, and the MAC address as an observation rather than a key
A proposed record-only protocol for an inventory of devices on a home network: one row per physical device with a household name and a printed identifier, a separate append-only table of dated observations (MAC address, hostname, IP lease, source such as the router's client list or ip neigh), and first-seen and last-seen derived from that table; Apple and Android documentation describe randomised per-network Wi-Fi MAC addresses, so the MAC column is not used as the key; no security assessment or router configuration advice is given.
-
First look at a misbehaving process with strace and tcpdump
Attach strace to see which system call a stuck process waits in and which files or sockets it touches; run tcpdump with a narrow filter and a packet count to see whether the peer answers at all. Both need privileges, both slow or fill things, so bound them in time and scope.
-
What idle timeouts do common NAT gateways and load balancers actually enforce, and what keep-alive interval survives them?
Open question: RFC 4787 and RFC 5382 set minimum NAT idle timeouts of two minutes for UDP and 2 hours 4 minutes for established TCP, but cloud NAT gateways, load balancers and mobile carriers are commonly reported to enforce much shorter values; which intervals have been observed, and what keep-alive settings keep long-lived connections alive across them?
-
Debugging HTTP with curl: verbose output, timing breakdown and forcing the connection
Use curl -v or --trace-ascii to see the exact request and response, --write-out with time_namelookup, time_connect, time_appconnect, time_starttransfer and time_total to locate where the time goes, and --resolve or --connect-to to send a request to one specific server while keeping the Host header and TLS name intact.
-
Server-side request forgery: fetching URLs the user supplies
When a server fetches a user-supplied URL it can be pointed at internal services and metadata endpoints; allow-list schemes and hosts, resolve and check addresses, disable redirects to private ranges, and prefer not fetching at all.
-
IPv6 enablement checklist for a website
Enable IPv6 in this order: address and firewall on the host, the server listening on [::] (nginx's IPv6 listener accepts only IPv6 by default, so keep the IPv4 one), a test over curl -6 against the address, then the AAAA record, then monitoring that probes each address family separately; Happy Eyeballs clients hide a broken IPv6 path behind a delay, while simpler clients fail outright.
-
Testing error paths and timeouts of outbound calls
List the failure classes of every dependency (refused, reset, connect timeout, read timeout, 5xx, 429, malformed or slow body), inject each with a test double at unit level and a fault-injecting proxy at integration level, and assert on the promised behaviour: attempts, backoff, typed errors, cleanup and no partial writes.
Lisible par machine : JSON