Blogs are like opinions. Everybody has one…

So you’ve set up a tunnel with your favorite tunnelbroker (for example Tunnelbroker.net or SixXS) but Firefox still refuses to “see the light” and insists on an IPv4 web. You simply need to type about:config in the address bar and change network.dns.disableIPv6 to false.

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.