Οταν το πρόβλημα του mail είναι πρόβλημα DNS

Τηλέφωνο πρωί πρωί από ένα φίλο (λες και μ’έβλεπε στον ύπνο του):

– Σε παρακαλώ, βοήθησέ μας γιατί έχουμε μιλήσει με 5 διαφορετικά άτομα για ένα πρόβλημα με τα email μας και όλοι μας λένε ότι να ‘ναι..

Ο ένας μας λέει ότι του απαντάει μια IP 205.κάτι και όχι μια 62.κάτι.άλλο όπως θα έπρεπε…

Ο άλλος μας λέει ότι όλα είναι OK!

Ο άλλος μας λέει να πάρουμε στον τάδε…

Help!

– Ποιό είναι το domain είπαμε;

– xyz-hotel.com και όταν στέλνουμε mail στο info@xyz-hotel.com παίρνουμε πίσω ένα ακαταλαβίστικο error από έναν mailer-daem…

Βήμα 1:
stsimb$ dig ns xyz-hotel.com @resolver1.opendns.com [1]
;; ANSWER SECTION:
xyz-hotel.com. 172800 IN NS ns1.pendingrenewaldeletion.com.
xyz-hotel.com. 172800 IN NS ns2.pendingrenewaldeletion.com.

– Δεν έχει πληρώσει για το domain του.. Να πάρει τηλ τον καταχωρητή του και όταν γυρίσει πάλι στους σωστούς NS όλα θα δουλέψουν automagically.

Δε χρειάστηκε καν να φτάσω στο βήμα 2 και να δω το μήνυμα λάθους του email…

Γιατί ποτέ κανείς δεν κοιτάει τα βασικά;

[1] Είναι απαραίτητο να ρωτήσεις κάποιον ΑΛΛΟ dns server και όχι τον δικό σου, που πιθανώς να έχει μια τοπική πραγματικότητα για το domain…

Multiple PTRs for the same IP

This is an answer to the frequently asked question “Why should I avoid Multiple PTRs for the same IP?” by Mark Andrews of ISC.

They are not a good idea because they don’t scale. In the
past large web hosters attempted to put a PTR record for
every virtual site on their servers. This ends up exceeding
the limits of normal query resolution support. You get
truncated TCP responses. You have to resort to AXFR to
retrieve the PTR records.

The DNS does not impose a order on returned records. If you
have multiple PTR records and you are trying to do access
control by name the application has to either list all the
names (if it looks at h_name) or try all the aliases. Not
all lookup mechanism supply all the names which inturn
leads to maintenance issues on the access lists.

Think of PTR records in the reverse tree as returning the
canonical name of the machine. Usually this would be the
name the machine knows itself as (fully qualified). If you
do this you won’t break the API’s for returning the name of
the machine based on the address.

Syzefxis DNS Views per VPN

Το ΣΥΖΕΥΞΙΣ είναι ίσως το μεγαλύτερο δημόσιο έργο δικτύωσης στην Ελλάδα, αφού συνδέει περισσότερους από 2000 δημόσιους φορείς σε όλη τη χώρα. Εκτός από τις 6 γεωγραφικές νησίδες (τηλεπικοινωνιακά διαμερίσματα) , είναι χωρισμένο και λογικά σε 4 MPLS VPNs [VPN-1 Νομαρχίες/Δήμοι/ΚΕΠ, VPN-2 Νοσοκομεία/Κέντρα Υγείας, VPN-3 Διαχειριστικές Αρχές, VPN-4 Στρατολογίες].

Το DNS του ξεκίνησε «κλασικά» όπως το 99.99% των περιπτώσεων που ξέρουμε, με ένα «internal» και ένα «external» view. Αντιγράφω από το http://www.syzefxis.gov.gr/Default.aspx?id=258&nt=18 το αρχικό spec:

Η υλοποίηση της Υπηρεσίας Ονοματολογίας θα πρέπει να γίνει με τέτοιο τρόπο ώστε να υποστηρίζεται η δυνατότητα για διαφορετική απάντηση ανάλογα με το χρήστη που κάνει την αίτηση. Για παράδειγμα, αν ένας χρήστης σε ένα Δήμο θέλει να προσπελάσει τον δικτυακό τόπο ενός άλλου Δήμου και βρίσκονται σε διαφορετικές νησίδες του Έργου «ΣΥΖΕΥΞΙΣ», η πρόσβαση θα πρέπει να γίνει εντός του ιδεατού κλειστού δικτύου που συνδέει τους Φορείς χωρίς να παρεμβάλλεται το Διαδίκτυο (αντιστοίχιση του εξυπηρετητή του δικτυακού τόπου σε private διεύθυνση). Αν τώρα ένας πολίτης θέλει να προσπελάσει το δικτυακό τόπο του εν λόγω Δήμου μέσω του Διαδικτύου, η υπηρεσία ονοματολογίας θα πρέπει να επιστρέψει μια public IP διεύθυνση η οποία να αντιστοιχεί μέσω NAT/PAT/reverse proxy στην private διεύθυνση του εξυπηρετητή του δικτυακού τόπου. Η υλοποίηση μπορεί να γίνει είτε με ρύθμιση του λογισμικού της υπηρεσίας είτε με εγκατάσταση διαφορετικών εξυπηρετητών που θα είναι υπεύθυνοι για την κάθε περίπτωση.

Δηλαδή όλα τα sites εντός ΣΥΖΕΥΞΙΣ πρέπει να κάνουν resolve στις private IPs για όλα τα VPN και τις νησίδες, και στις public IPs για το Internet.

Κάπου στην πορεία όμως (~Μάρτης 2007) τα specs άλλαξαν και ζητήθηκε το παρακάτω:

  • Φορέας που επιθυμεί να δει οποιαδήποτε εφαρμογή άλλου φορέα εντός του ίδιου VPN θα πρέπει να πληροφορείται από τις διατάξεις DNS για την private IP, του host που θέλει να προσπελάσει.
  • Φορέας που ανήκει σε άλλο VPN δεν θα πρέπει να επικοινωνεί δικτυακά με το συγκεκριμένο φορέα παρά μόνο αν η εφαρμογή είναι published στο Internet
    «…Για παράδειγμα αν δεν έχει ζητηθεί ειδικά κάποια «επικάλυψη» των VPNs δεν πρέπει να μπορούν οι Δήμοι να βλέπουν μεσα από το VPN-1 το portal της Στρατολογίας (www.stratologia.gr) (VPN-4) αλλά να το βλέπουν από το διαδίκτυο. …»
    Σε αυτή την περίπτωση η διάταξη DNS θα δίνει την public IP του host.

Με απλά λόγια, όταν κάποιος πχ. από το δήμο Κατερίνης ζητήσει να δεί το site του δήμου Αμαρουσίου, θα πρέπει να πάρει το Internal IP (και ας είναι σε διαφορετική νησίδα, είναι όμως στο ίδιο VPN), αλλά αν ζητήσει να δει το site του Νοσοκομείου Κατερίνης, θα πρέπει να πάρει το public ip (γιατί είναι σε άλλο VPN).

Τα δυο αρχικά Views έγιναν 6 (external, vpn1, vpn2, vpn3, vpn4, vpn-isp) και σήμερα 10 (προστέθηκαν vpn21, vpn22, vpn23, vpn24 λόγω επέκτασης του ΣΥΖΕΥΞΙΣ).

Το setup είναι πιο περίπλοκο από το αρχικό, αλλά με λιγότερες από 100 γραμμές perl που βγάζουν τα κατάλληλα bind config files το αποτέλεσμα είναι φανταστικό και αποτελεί το μοναδικό setup που ξέρω μέχρι σήμερα που ξεφεύγει από το απλό internal/external view!

DNS server πίσω από firewall?

Το πρόβλημα…

There are lots of badly constructed firewalls.

  • Some block source port != 53
  • Some block source port < 1024
  • Some block source port 1024-1030 (rpc ports)
  • Some block source port ~7000 (irc ports)

If you have a nameserver you should allow traffic to port 53
on the nameserver regardless of the source port. It should
also allow reply traffic to any destination port.

…ο σωστός τρόπος

With a first match firewall you should have rules like:

state-full firewall

  • check-state ; allow inbound replies
  • allow any to nameserver 53 in ; allow inbound queries
  • allow nameserver 53 to any out ; allow replies
  • allow any to any 53 out keep-state ; allow outbound queries
  • <put your general blocks here>

state-less firewall (query-source port 53)

  • allow tcp established
  • allow any to nameserver 53 in ; allow inbound queries and inbound replies
  • allow nameserver 53 to any out ; allow replies
  • allow udp any 53 to any 53 out ; allow outbound queries
  • <put your general blocks here>

If you are worried about too much state being kept with the state-full
firewall you can do it as a state-less firewall for the recursive
servers by inserting a rule like this before the keep-state rule

  • allow udp <recursive server> 53 to any 53 out

Bind has a built in list of ports for which it will not
responed to with error messages. It will also not reply
to responses.

(ref)

Τι καταλήγει στον DNS ενός ISP;

Με χρήση του dnstop για 10 μόνο λεπτάκια βρίσκει κανείς πολύ εύκολα..

  • Reverse από rfc1918 domains (κατα σειρά εμφάνισης)
    • *.168.192.in-addr.arpa
    • *.10.in-addr.arpa
  • Unknown TLDs (κατα σειρά εμφάνισης)
    • lvs_proxy
    • *.domain_not_set.invalid
    • *.lan
    • *.local
    • wpad
    • *.gateway
    • *.none
    • localhost
  • Top invalid destinations (κατα σειρά εμφάνισης)
  • Top destinations (κατα σειρά εμφάνισης)
    • ntp servers: time-nw.nist.gov, time.nist.gov, stdtime.gov.tw
    • root-servers.net
    • myspacedn.com
    • google.com
    • yahoo.com
    • dyndns.org
    • microsoft.com
    • facebook.com
    • msn.com
    • hi5.com
    • no-ip.info
    • youtube.com
    • google-analytics.com
    • live.com
    • intel.com
    • bitcomet.org
    • googlesyndication.com
    • imageshack.us
    • photobucket.com
    • thepiratebay.org
    • doubleclick.net
    • ath.cx

Επίσης μπορείς εύκολα να καταλάβεις

  • ποιοί είναι mail servers (MX queries, PTR queries, queries σε dnsbls)
  • ποιοί κάνουν mail spam πιθανώς από κάποιο worm infection (από τα συνεχόμενα MX queries χωρίς άλλα checks)
  • ποιοί σε έχουν βάλει για dns forwarder ..

DNS Survey Oct 2007

Το DNS Survey που έγινε τον Οκτώβριο από το Measurement Factory (με sponsor την Infoblox) έχει ορισμένα πολύ ενδιαφέροντα στατιστικά για τους NS του Internet..

Μερικά γρήγορα συμπεράσματα:

  • Το Bind 9 ζει και βασιλεύει (αλλά ο Nominum CNS έχει 20%!).
  • Υπάρχουν ακόμα πολλοί resolvers που επιτρέπουν recursion και αρκετοί που επιτρέπουν zone transfers (γιατί έτσι μάθαμε το Internet :)).
  • IPv6 και DNSSEC ακόμα …τίποτα!
  • Ευτυχώς οι περισσότεροι NS είναι topologically dispersed σε κάτι μεγαλύτερο απο /24. Μάλλον είναι μόνο Ελληνικό το φαινόμενο τα domains να έχουν δύο NS οι οποίοι είναι ip aliases στο ίδιο μηχάνημα..
  • Δυστυχώς μόνο το 50% των NS είναι consistent μεταξύ registrar και actual zone.

Μπορείτε επίσης να διαβάσετε την ανάλυση των αποτελεσμάτων από τον Cricket Liu (2 σελίδες executive summary, θέλει registration και μετά η infoblox στέλνει μια στο τόσο ενημερωτικά για τα προϊόντα της, well targeted και συνήθως ενδιαφέροντα).