Ο Βαγγέλης έκανε στο twitter δύο ενδιαφέρουσες ερωτήσεις:

@hakmem ερώτηση: δεν είναι καφρίλα να ζήτας από SMTP να έχει και Valid RDNS;

και αφού του απάντησα πως δεν είναι:

@hakmem έστω ένα VPS με 1 IP που τρέχει SMTP για 5-6 virtual domains, αν βάλεις reverse dns based block το χάσαμε το κορμί πατριώτη

Για να γίνει κατανοητό το γιατί, θα χρησιμοποιήσω το test case που δίνει ο Βαγγέλης. Έστω VPS με IP address 10.2.3.4 και όνομα server-vps.example.com. Έστω επίσης και 5 virtual domains που τρέχουν πάνω σε αυτόν, τα example-1.com έως και example-5.com. Κατά πως συνηθίζεται ο mail server για κάθε ένα από αυτά ονομάζεται mail.example-1.com, mail.example-2.com κ.ο.κ. Και οι πέντε mail server έχουν την ίδια ακριβώς IP address, την 10.2.3.4.

Όταν κάποιος θέλει να στείλει ένα email στον user@example2.com συμβουλεύεται το DNS για τα MX RR. Τα MX RR είναι η απάντηση στην ερώτηση “ποιος ξέρει να παραδώσει την αλληλογραφία προς χρήστες στο example2.com;”. Στο παράδειγμα η απάντηση είναι ο mail.example2.com. Στη συνέχεια συμβουλεύεται το DNS για τα A RR. Τα A RR είναι η απάντηση στην ερώτηση “ποια είναι η διεύθυνση του mail.example2.com;”. Θα λάβει την απάντηση 10.2.3.4 και στη συνέχεια θα κάνει τα προβλεπόμενα από το πρωτόκολλο SMTP ώστε να συνδεθεί και να παραδώσει την αλληλογραφία. Σημειώστε πως και τα δύο ερωτήματα που έγιναν στο DNS είναι παραδείγματα forward lookup.

Όταν σε κάποιον server συνδέεται κάποιος ώστε να χρησιμοποιήσει μια υπηρεσία που προσφέρει, το μόνο που ξέρει ο server είναι η διεύθυνση που χρησιμοποιεί ο αιτών. Τον “παλιό καλό καιρό” που το spam δεν ήταν πρόβλημα, ένας mail server θα δεχόταν οποιδήποτε μήνυμα από οποιονδήποτε και θα έκανε ότι μπορούσε για να παραδοθεί στον προορισμό του. Επειδή οι καιροί έχουν αλλάξει κανείς δεν είναι τόσο ανεκτικός και αρκετοί mail servers στα πλαίσια πολιτικών που εφαρμόζουν θέλουν να γνωρίζουν το όνομα αυτού που συνδέεται πάνω τους. Για να το κάνουν αυτό ρωτούν για το PTR RR που σχετίζεται με την συνδεόμενη IP address. Εάν το reverse delegation δεν είναι ορισμένο σωστά ή εάν δεν συμφωνούν το A RR για το όνομα με το PTR RR που δίνει το DNS για τη διεύθυνση, τότε είναι πιθανό η επικοινωνία να μη γίνει αποδεκτή και το email να μην παραδοθεί.

Παρόλο που κανείς μπορεί να οδηγηθεί στο συμπέρασμα πως πρέπει να υπάρχει ένα PTR για κάθε όνομα που κάνει χρήση της 10.2.3.4, αυτό που είναι απαραίτητο είναι ένα από όλα (οποιοδήποτε) να συμφωνεί με το PTR RR. Το ενδεικνυόμενο στη συγκεκριμένη περίπτωση, για διαχειριστικούς λόγους επειδή έχουμε να κάνουμε με virtual domains, είναι το PTR να δείχνει στο “πραγματικό” όνομα του server, δηλαδή στο vps.example.com. Ή όπως πιο απλά το έθεσε ο Γιώργος Κεραμιδάς:

@vtripolitakis Το σημαντικό σε αυτό που είπε ο @hakmem είναι ότι η αντιστοιχία name ↔ address είναι M ↔ 1. Απλά τυχαίνει συχνά M=1

Γυρνώντας πίσω στην απάντηση που έδωσα στην πρώτη ερώτηση του Βαγγέλη:

@vtripolitakis Όχι. Καφρίλα είναι να κόβεις με βάση το HELO/EHLO

Δεν είναι πρόβλημα να μην αποδέχεται κανείς τη σύνδεση επειδή δεν υπάρχει PTR record. Πρόβλημα είναι η μη αποδοχή σύνδεσης για προβληματικό HELO. Και αυτό γιατί τα RFC 1123, 2821 και 5321 το απαγορεύουν. Το RFC5321 γράφει:

However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. Information captured in the verification attempt is for logging and tracing purposes.

Αλλά για την ιστορία του SMTP-HELO θα ακολουθήσει επόμενο post.

Following a previous discussion on this blog I just posted the following question on Hacker News:

Would you click on (or type) a link that contains Punycode? Or even on a link that contains localized characters? Example:

http://www.εδετ.gr and http://www.xn--pxabb4d.gr (they are the same site).

Or would you consider them phising “faster” than a latin spelled URL?

(The example I am giving is a legitimate site)

Comments are not closed, but please comment on Hacker News if you want to.

Αφορμή για το post αυτό είναι μια ιστορία που έχει συμβεί περισσότερο από δύο χρόνια πριν. Ένα μεσημέρι μας πήραν τηλέφωνο από ένα δημόσιο οργανισμό για τον οποίο είμαστε Καταχωρητές στο .GR και μας παραπονέθηκαν πως αντιμετωπίζουν προβλήματα DNS resolving και πιο συγκεκριμένα δεν μπορούσαν να στείλουν email προς κάποια Πανεπιστήμια, “επειδή δεν ήταν στο DNS”.

Πριν συνεχίσω, πρέπει να γίνει κατανοητό πως η δουλειά του Καταχωρητή είναι κυρίως γραφειοκρατική και δευτερευόντος τεχνική. Μπορείς να έχεις Καταχωρητή τον Α, DNS operator τον Β, email στον Γ και web hosting στον Δ ή διάφορους συνδιασμούς των παραπάνω. Συνήθως όμως είτε οι Καταχωρητές προσφέρουν τις υπηρεσίες αυτές σαν value added services, είτε οι hosting providers παρέχουν (και) υπηρεσίες Καταχωρητή.

Υπάρχει όμως ακόμα μια λεπτή διαφορά. Τα παραπάνω, συμπεριλαμβανομένων των υπηρεσιών του Καταχωρητή στο .GR, αφορούν θέματα forward DNS resolving. Χοντρά-χοντρά το forward DNS resolving αφορά τη διαδικασία της “μετάφρασης” από ένα όνομα σε μια IP address. Π.χ. όταν ο web browser σας ζητά να συνδεθεί στο www.google.com, μέσω του DNS ζητά να συνδεθεί στην διεύθυνση 74.125.53.99.

Το παραπάνω είναι διαφορετικό από το πρόβλημα του ΝΠΔΔ που μας τηλεφώνησε. Όταν σε ένα server συνδέεται ένας υπολογιστής για να κάνει χρήση μιας υπηρεσίας, ο server γνωρίζει την IP address του υπολογιστή που συνδέθηκε πάνω του. Για να μάθει το όνομά του πρέπει να κάνει αυτό που ονομάζεται reverse DNS lookup (τεχνικά όχι κάτι διαφορετικό από το forward DNS lookup). Μια συνήθης πολιτική πρόσβασης είναι να μην επιτρέπεται η πρόσβαση σε κάποια υπηρεσία όταν δεν μπορεί να διασταυρωθεί το όνομα του μηχανήματος που προσπαθεί να συνδεθεί. Το πρόβλημα που είχε το συγκεκριμένο ΝΠΔΔ, ήταν πως αυτή η διασταύρωση δεν μπορούσε να γίνει. Θεώρησαν σωστό λοιπόν να μιλήσουν με τον Καταχωρητή τους για το πρόβλημα αυτό.

– Μίλησαν όμως με τον σωστό Καταχωρητή;

Όχι. Οι καταχωρητές που διαμεσολαβούν για την εκχώρηση ενός domain (είτε στο .GR, είτε σε κάποιο άλλο TLD ή ccTLD) στη γενική περίπτωση δεν είναι οι ίδιοι με τους “αντίστροφους” (ας μου επιτραπεί ο όρος) Καταχωρητές. Συνήθως όμως ο ISP σας είναι και ο “αντίστροφος” Καταχωρητής που απέδωσε την διεύθυνση IP με την οποία συνδέεται κάποιος στο Internet.

Το “φάσμα” των IP διευθύνσεων το διαχειρίζεται η IANA. Αυτή εκχωρεί address blocks στα Regional Internet Registries. Για τον ευρωπαϊκό χώρο το αντίστοιχο RIR είναι το RIPE NCC. Το RIPE με τη σειρά του εκχωρεί block διευθύνσεων στα Local Internet Registries που είναι μέλη του. Οι ISP ζητάνε διευθύνσεις τόσο για τις ανάγκες τους, όσο και για τις ανάγκες των πελατών τους από ένα LIR. Συνηθέστερα οι ίδιοι οι ISP λειτουργούν και ως LIR.

Έτσι λοιπόν το bookkeeping του reverse DNS είναι μια δραστηριότητα που ανήκει στην αλυσίδα IANA → RIR → LIR → ISP (ή οργανισμός στον οποίο έχει αποδοθεί block διευθύνσεων). Επομένως ο Καταχωρητής σας δεν είναι απαραίτητα τμήμα αυτής της αλυσίδας.

Πίσω στην ιστορία μας: Τι είχε συμβεί; Κάποια στιγμή, κάποιος στο ΝΠΔΔ αποφάσισε να κάνει format / reinstall τους DNS servers. Στην πορεία αποφάσισε να αλλάξει και τις IP addresses των servers. Μετά από μερικές μέρες και αφού διαπίστωσε πως κανείς από το Internet “δεν τον έβλεπε” επικοινώνησε με εμάς (είμαστε οι Καταχωρητές του στο .GR, αλλά όχι ο ISP του) ώστε να οριστούν οι νέες διευθύνσεις στο Μητρώο του .GR. Λίγο καιρό μετά ξαναεπικοινώνησε “επειδή δεν ήταν στο DNS” ενώ οι αλλαγές είχαν γίνει. Ναι, αλλά το LIR του δεν είχε ενημερωθεί για αυτές. Το ενημέρωσε και το πρόβλημα λύθηκε.

Αν τα παραπάνω σας φαίνονται κουραστικά και πολύπλοκα είναι γιατί είναι.

Από τις 4 Ιουλίου του 2005 υποστηρίζονται Ελληνικοί χαρακτήρες στο .gr. Αυτό όμως δεν φαίνεται να συγκινεί τους webmasters διαφόρων εκπομπών. Πριν λίγο κάνοντας zapping έπεσα στο www.katipsinetai.gr. Πέρσυ ήταν η www.ellinikiradiofonia.gr.

Υπάρχει κάποιος λόγος που δεν είναι ελκυστικά τα ονόματα DNS με ελληνικούς χαρακτήρες και αντίθετα τα λατινικά είναι προτιμητέα ακόμη και “ανορθόγραφα”;