Μια σειρά από switches της Cisco έχει «κολλήσει» σε έναν κύκλο συνεχών επανεκκινήσεων λόγω ενός προβλήματος DNS. Η αιτία φαίνεται να είναι μια αλλαγή στην Cloudflare, στην οποία τα συστήματα της Cisco αντιδρούν λανθασμένα.
Το firmware του δικτυακού εξοπλισμού ερμηνεύει τα σφάλματα αναζήτησης DNS ως κρίσιμα σφάλματα συστήματος.
Οι διαχειριστές εντόπισαν ότι τα προβλήματα με τους Cisco Switches οφείλονται σε μια λανθασμένη προσαρμογή DNS που εφαρμόστηκε από την Cloudflare.
Ο δημόσιος DNS resolver 1.1.1.1 της εν λόγω εταιρείας διαδικτύου, μετά από μια πρόσφατη ενημέρωση λογισμικού, χρησιμοποιεί διαφορετική σειρά στις DNS‑απαντήσεις για αιτήματα μετατροπής ονομάτων τομέα σε IP διευθύνσεις.
Ως αποτέλεσμα, οι DNS‑clients, όπως οι Switches της Cisco, λαμβάνουν απαντήσεις σε διαφορετική μορφή.
Αυτό «συγκρούεται με τις προσδοκίες ορισμένων υλοποιήσεων DNS‑clients», όπως αναφέρει η Cloudflare σε ανακοίνωσή της για το πρόβλημα. Φαίνεται ότι αυτό αφορά το λογισμικό DNS στους Switches της Cisco.
Το firmware αυτών των δικτυακών συσκευών δεν χειρίζεται σωστά τις «ασυνήθιστες» DNS‑απαντήσεις: τις θεωρεί κρίσιμα σφάλματα και, ως αντίδραση, προχωρά σε επανεκκίνηση ολόκληρου του switch.
Μετά την επανεκκίνηση, τα νέα DNS αιτήματα οδηγούν ξανά στα ίδια σφάλματα και έτσι σε νέες επανεκκινήσεις, σύμφωνα με το Bleeping Computer.
Ο βρόχος των επανεκκινήσεων φαίνεται να επηρεάζει μόνο τον εξοπλισμό Cisco που χρησιμοποιεί το 1.1.1.1 για τα DNS αιτήματά του. Σε αναρτήσεις στο Reddit και σε συζητήσεις στην κοινότητα της Cisco, διαχειριστές αναφέρουν ότι η χρήση άλλων DNS resolvers αποτρέπει το πρόβλημα.
Σύμφωνα με αυτές τις αναφορές, η αφαίρεση του 1.1.1.1 από τις ρυθμίσεις βοηθά στην επίλυση του προβλήματος των επανεκκινήσεων.
Η Cloudflare έχει επαναφέρει την προηγούμενη έκδοση του λογισμικού και δηλώνει ότι με αυτόν τον τρόπο το σφάλμα έχει διορθωθεί.
Μαθήματα αξιοπιστίας από το περιστατικό Cisco–Cloudflare
Το συγκεκριμένο περιστατικό αναδεικνύει πόσο «εύθραυστα» μπορεί να είναι σύγχρονα δίκτυα όταν βασίζονται σε εξωτερικές υπηρεσίες όπως οι δημόσιοι DNS resolvers.
Ακόμα και κρίσιμος εξοπλισμός υποδομής –όπως switches και routers– συχνά στηρίζεται σε υπηρεσίες τρίτων για βασικές λειτουργίες, δημιουργώντας ένα κρυφό single point of failure πέρα από τον άμεσο έλεγχο του οργανισμού.
Σε επίπεδο σχεδιασμού λογισμικού, το πρόβλημα δείχνει πόσο επικίνδυνο είναι όταν ένα client υλοποιεί «εύθραυστη λογική» γύρω από φορμά απαντήσεων. Το DNS πρωτόκολλο επιτρέπει ευελιξία στη σειρά και στη δομή των εγγραφών.
Αν η συσκευή υποθέτει ότι οι απαντήσεις έχουν πάντα συγκεκριμένη μορφή, μια απολύτως έγκυρη αλλά ελαφρώς διαφορετική απόκριση μπορεί να ερμηνευτεί ως σφάλμα.
Ακόμη χειρότερα, εδώ ένα απλό σφάλμα δικτύου μεταφράστηκε σε «κρίσιμο σφάλμα συστήματος» που οδηγεί σε reboot του εξοπλισμού, κάτι που παραβιάζει την αρχή της ανθεκτικότητας: τα σφάλματα εισόδου δεν πρέπει να ρίχνουν ολόκληρη τη συσκευή.
Για τους διαχειριστές δικτύων, ένα βασικό μάθημα είναι η προσεκτική χρήση δημόσιων DNS στη διαχείριση υποδομής.
Καλή πρακτική είναι η ύπαρξη εσωτερικού recursive resolver (ή ζεύγους για πλεονασμό), ο οποίος προωθεί ερωτήματα σε πολλαπλούς upstream παρόχους (ISP, 1.1.1.1, 8.8.8.8 κ.λπ.).
Έτσι, οποιαδήποτε αλλαγή ή βλάβη σε έναν πάροχο δεν επηρεάζει άμεσα τις ίδιες τις δικτυακές συσκευές.
Παράλληλα, η χρήση περισσότερων του ενός DNS servers στις ρυθμίσεις (π.χ. primary/secondary) μειώνει την πιθανότητα πλήρους διακοπής.
Η παρακολούθηση (monitoring) παίζει κρίσιμο ρόλο: ανωμαλίες όπως αυξημένος ρυθμός επανεκκινήσεων, απώλεια SNMP traps ή απότομη πτώση στην προσβασιμότητα management interfaces πρέπει να ενεργοποιούν άμεσα ειδοποιήσεις.
Ένα έτοιμο runbook, που να περιγράφει πώς αλλάζουμε προσωρινά DNS ρυθμίσεις μέσω out‑of‑band πρόσβασης ή κονσόλας, μπορεί να περιορίσει τη διάρκεια της διαταραχής.
Από πλευράς κατασκευαστή, περιστατικά αυτού του τύπου υπογραμμίζουν την ανάγκη για εκτενή δοκιμή συμμόρφωσης με τα RFCs και για regression tests απέναντι σε διάφορους δημοφιλείς DNS resolvers.
Επίσης, απαιτείται γρήγορη επικοινωνία με τους πελάτες, ξεκάθαρες οδηγίες προσωρινής αντιμετώπισης (workarounds) και, όπου χρειάζεται, διορθωτικά firmware.
Καθώς τα δίκτυα γίνονται όλο και πιο software‑defined και εξαρτημένα από APIs και cloud υπηρεσίες, ο «σχεδιασμός για αποτυχία» (failure‑aware design) παύει να είναι πολυτέλεια και γίνεται προϋπόθεση για πραγματικά ανθεκτικές υποδομές.
