Google Public DNS s a free, global Domain Name System (DNS) resolution service, that you can use as an alternative to your current DNS provider. The service’s DNS servers IP addresses are easily memorable even by end users (who the service aims to help most) and they are:

• 8.8.8.8 and
• 8.8.4.4

There are other uses for the service. Many system administrators use it for troubleshooting DNS problem in their infrastructure as an objective third party with a DNS view from “outside” their network (plus you can say to your manager that hey this is Google’s DNS view of this zone setup when nothing else helps).

Those of us who host domains, web sites and mail infrastructures have at times faced the problem that domains come and go somewhere else. However, domain owners / administrators / subcontractors / etc often neglect to inform the previous infrastructure that the domain has a new home. Then appears the phenomenon that most of the Internet knows how to access the web site (and where to route email) at the new home, with the exception of the previous ISP or hosting provider. Most of the times the previous hosting provider will find out when the contract runs out, which at times may take as long as 6 months (and I’ve seen longer times too).

In a few cases the previous hosting provider will find about the move because of complaints by its current customers who cannot reach the domain, the old customer complaining that there exist people who do not see the new site (but hey did you ever ask us to put it down?) or simply by pure chance.

In such cases as above the objectiveness of the Google Public DNS system can be of use to the DNS master who wants to maintain a clean setup. One can feed the following script with a file that contains one domain per line (the domains that you host) and ask Google who does it see as their designated DNS servers. In the old days one would ask a fellow admin at another ISP for shell access (I use SDF for similar purposes) or for query access. There is no need for that now :)

#!/usr/bin/perl
# This hack assumes that your nameservers are under the example.com domain

$ns = "8.8.8.8";
## $ns = "8.8.4.4";

while(<>) {
	next if (m/^#/);
	chop;
	$domain = $_;
	open DIG, "dig \@$ns $domain ns +short|" or die;
	while(<DIG>) {
		chop;
		next if (m/\.example\.com\.$/);
		print "$domain $_\n";
	}
	close DIG;
}

As is shown by the small script above the idea is pretty simple and can easily be customized to suite any local setup.

@dstergiou asked:

I am looking for a tool to see under which TLDs a domain is registered. E.g. check all TLDs for domains matching “test123”

One way to check is to visit registrars that cover TLDs and ccTLDs (like EuroDNS or Gandi) and submit your query to their forms. However since (at least TTBOMK) none of them offers any query API to check programmatically, one can script his way to an almost complete solution. ICANN provides a list of all available TLDs and we can iterate over it:

#!/usr/bin/perl

## To grab the TLDs: wget -c http://data.iana.org/TLD/tlds-alpha-by-domain.txt

use Net::DNS;

$check = shift or die;

open F, "< tlds-alpha-by-domain.txt" or die;
while (<F>) {
        next if (m/^#/);
        chop;
        push @tlds, $_;
}
close F;

foreach $i (@tlds) {
        my $domain = $check . "." . $i . ".";
        my $res = Net::DNS::Resolver->new;
        my $query = $res->query($domain, "NS");

        if ($query) {
                ## foreach $rr (grep { $_->type eq 'NS' } $query->answer) { print $rr->nsdname, "\n"; }
                print $domain, "\n";
        }
}

The above hack comes with three problems:

• It uses Net::DNS which makes it a little slow. There is room for improvement.
• It finds out about registered domain names that have domain name servers that answer queries about them. This is not always the case. For example in .GR one can register a domain without having it served.
• It also does not take into account strict domain hierarchies, like .co.uk, .net.uk, .org.uk but minimal changes are needed to test that too.

Somewhat incomplete as a solution, but adequate as a 5 minute hack for most purposes.

P.S. @stsimb offers a similar solution using dig:

for sfx in TLDs; do dig +short ns test123.$sfx; done

adnsrblcheck is a DNSBL check tool that I wrote sometime in 1999. At the time I had come across the ADNS resolver library and I wanted to try it out. So I grabbed a copy of rblcheck (then at version 1.4) and modified it to use ADNS instead of the standard resolver library.

Some time in 2003 Stephen Friedl grabbed adnsrblcheck.c, did his own modifications and released it back as arblcheck. He even provides a Windows port.

In December 2008, and while I was supposed to be performing ns2 simulations, I was struck by a severe case of structured procrastination which led to me picking up the tool again and doing some minor modifications. Eventually I pulled myself together, dealt with the deadlines and (almost) forgot about the tool. That is until today: adnsrblcheck, a DNSBL check tool using ADNS, is available again and you can grab it via subversion from here:

svn checkout https://rainbow.cs.unipi.gr/svn/adnsrblcheck

Από το INBOX μου:

Γιώργο,
Μπορώ να κάνω nslookup χρησιμοποιώντας άλλον dns π.χ. dns1.ΧΧΧΧ.gr ;

Παλιά μπορούσα αλλά τώρα δεν μπορώ από κανέναν άλλο να δω πλην από ΥΥΥΥ. Γνωρίζεις κάτι;

Οι περισσότεροι ISP δεν επιτρέπουν recursive queries στους DNS servers τους “έξω” από το δίκτυό τους. Το (φιλικό) Internet όπως το μάθαμε έχει τελειώσει. Οπότε η αμέσως καλύτερη επιλογή είναι οι server του Google:

– 8.8.8.8 και
– 8.8.4.4

και όχι μόνο για DNS lookups, αλλά και για traceroute και ping.

Ο Βαγγέλης έκανε στο 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 με ελληνικούς χαρακτήρες και αντίθετα τα λατινικά είναι προτιμητέα ακόμη και “ανορθόγραφα”;