↓ Skip to main content
u-random
u-random
  1. Concetti/

DNS e HTTP in una LAN con switch

·4 mins
base
Network-Defense Dfir
Alessio Barnini
Author
Alessio Barnini
Table of Contents
DNS e HTTP in una LAN con switch

Cosa fa
#

In una LAN flat con switch L2, il client risolve un hostname via DNS query UDP porta 53, poi apre una connessione HTTP TCP verso l'IP restituito. Nessun gateway necessario.

TL;DR
#

# Flusso completo da Pc Barno (192.168.1.1) a www.sito.it

1. Browser chiede "chi è www.sito.it?"
2. DNS query UDP → 192.168.1.10:53
3. DNS risponde: "192.168.1.20"
4. HTTP GET TCP → 192.168.1.20:80
5. Server risponde con la pagina

dns-http-lan-packet-tracer.webp

Tutto avviene dentro la stessa subnet 192.168.1.0/24. Lo switch forwarda i frame in base al MAC address. Nessun router coinvolto.

Topologia dell'esercizio
#

Pc Barno (192.168.1.1)
    └── Fa0 → Switch1 (Fa0/1)
                 ├── Fa0/2 → Server0 — DNS SERVER (192.168.1.10)
                 └── Fa0/3 → Server1 — HTTP SERVER (192.168.1.20)

Switch utilizzato: Cisco 2960-24TT — opera a L2, nessun routing.

Configurazione IP dei dispositivi
#

DispositivoIPSubnet MaskGatewayDNS Server
Pc Barno192.168.1.1255.255.255.00.0.0.0192.168.1.10
Server0 (DNS)192.168.1.10255.255.255.00.0.0.00.0.0.0
Server1 (HTTP)192.168.1.20255.255.255.00.0.0.00.0.0.0

Il gateway è 0.0.0.0 su tutti: non esiste nessun router in questa topologia.

Perché il gateway non serve
#

Lo switch opera a L2. Quando Pc Barno vuole raggiungere 192.168.1.10:

  1. Calcola: destinazione nella stessa subnet? Sì (/24 su entrambi)
  2. Invia ARP request: "chi ha 192.168.1.10?"
  3. Lo switch forwarda il frame alla porta corretta (Fa0/2)
  4. Server0 risponde con il suo MAC
  5. Nessun gateway attraversato

Il gateway serve solo per uscire dalla subnet verso un'altra rete, e richiede un router (o switch L3 con routing abilitato).

Il record DNS: A Record
#

In Packet Tracer, su Server0 (tab Services → DNS):

No.NameTypeDetail
0www.sito.itA Record192.168.1.20

Il record di tipo A mappa un hostname a un indirizzo IPv4. È il tipo base della risoluzione DNS.

Chi ha bisogno del DNS server e chi no
#

DispositivoHa bisogno del DNS?Perché
Pc BarnoSìInizia richieste usando nomi (www.sito.it)
Server0 (DNS)NoRisponde a richieste, non le inizia
Server1 (HTTP)NoRiceve connessioni in ingresso, non risolve nomi
Regola Generale

Chi fa richieste usando nomi ha bisogno del DNS. Chi risponde a richieste no. Eccezione nel mondo reale: un server che deve contattare API esterne, mandare email o aggiornare pacchetti ha bisogno di un DNS configurato, perché anche lui inizia richieste verso hostname

Il PDU della DNS query (da Packet Tracer)
#

Decostruendo il pacchetto in uscita da Pc Barno si vedono 4 layer:

Ethernet II
  SRC: 0001.C789.A4D1  (MAC di Pc Barno)
  DST: 0001.436A.0B4D  (MAC di Server0)
  TYPE: 0x0800          (IPv4)

IP
  SRC IP: 192.168.1.1
  DST IP: 192.168.1.10
  TTL: 128
  PRO: 0x11             (UDP)

UDP
  SOURCE PORT: 1042     (porta ephemeral casuale)
  DEST PORT:   53       (DNS, sempre)

DNS Header
  QDCOUNT: 1            (una domanda)
  ANCOUNT: 0            (nessuna risposta ancora)

DNS Query
  NAME: www.sito.it
  TYPE: 1               (A Record — voglio un IPv4)

In tcpdump questo pacchetto apparirebbe come:

IP 192.168.1.1.1042 > 192.168.1.10.53: UDP, length 35
# con -v:
33947 A? www.sito.it. (35)

Perché DNS usa UDP invece di TCP
#

  • Leggero: nessun overhead di connessione
  • Senza ordine: una singola risposta, non c'è sequenza da garantire
  • Senza three-way handshake: con TCP sarebbero almeno 7 pacchetti (3 handshake + 1 query + 1 risposta + 2 chiusura); con UDP sono 2 (domanda + risposta)

Eccezione: DNS usa TCP quando la risposta supera 512 byte, ad esempio nei trasferimenti di zona tra server DNS (zone transfer). Traffico DNS su TCP da un client normale è anomalo e vale la pena investigarlo.

Errore tipico in Packet Tracer
#

Configurare il record DNS sul server sbagliato. Se il record www.sito.it → 192.168.1.20 è su Server1 (HTTP server) invece che su Server0 (DNS server), il PC invia la query a 192.168.1.10 (Server0), che non ha il record e risponde con NXDOMAIN. Nessuna richiesta HTTP parte perché il client non ha un IP da contattare.

Analogia
#

Il DNS è una rubrica telefonica: conosci il nome (www.sito.it), non sai il numero (192.168.1.20). Chiedi alla rubrica, ottieni il numero, poi chiami direttamente. Senza rubrica hai solo un nome e non sai chi chiamare.

Scenario Reale
#

Questa topologia corrisponde a un VPS su Hetzner o AWS con Docker, Traefik e Nginx. Il DNS pubblico (Cloudflare, Route53) ha il record A che punta all'IP del VPS. Traefik riceve la richiesta, legge l'header Host: www.sito.it e la instrada al container Nginx corretto. Stesso IP pubblico, decine di siti diversi grazie al virtual host. Il meccanismo è identico a questo lab: risoluzione DNS → connessione TCP verso l'IP restituito.

Risorse Esterne
#

https://www.youtube.com/watch?v=9BdpA_-PHhY&list=PLod5uVuFMqhaEu_Qn9MmUbT6AiASm9M-ja&index=4

Collegato a
#

  • osi-model — i 4 layer visibili nel PDU (Ethernet, IP, UDP, DNS)
  • nat-concept — in questa LAN non c'è NAT; in produzione il traffico esce tramite NAT del router
  • blog-arp-poisoning — ARP è coinvolto nella fase di risoluzione MAC prima della DNS query
  • network — categoria

Related