soacheck – report changes in domain serial numbers


I wanted to check how often a domain gets updated, so I quickly put together soacheck.

I assume that everybody increments the SOA serial number when they make a change or generate the zone file. But strictly speaking, they don’t have to do it (they can use some other way to sync changes to all their NSs and make them available).


List the zones you’re interested in file «zones-to-check». Execute soacheckd in your crontab (no need to run as root), as often as you like. e.g.

* * * * * /path/to/soacheckd > /dev/null

Check the results in soacheckd.log.

[stsimb@pipitsa soacheck]$ grep " gr. " soacheckd.log | tail
Fri Feb 1 04:51:01 EET 2013 soacheckd[22093] gr. serial changed from 1301312194 to 1302010099
Fri Feb 1 07:51:02 EET 2013 soacheckd[19481] gr. serial changed from 1302010099 to 1302010401
Fri Feb 1 10:52:01 EET 2013 soacheckd[18500] gr. serial changed from 1302010401 to 1302010695
Fri Feb 1 13:52:01 EET 2013 soacheckd[19079] gr. serial changed from 1302010695 to 1302011000


  • Record answers from authoritative servers (answers now are from system resolver’s cache)
  • Record answers from multiple servers
    • use a set of public dns servers
    • use some dns-lg instances around the world
  • Make multiple checks in parallel
  • Record changes of other RR types, e.g. A, AAAA, CNAME, PTR etc
  • Trigger some event on change

IPv6 reverse DNS in 60″

Your allocation: 2001:db8/32
You LAN: 2001:db8:2:2001/64
Your device: 2001:db8:2:2001::11 (mydevice.local)

Let «host» do the dirty work for you!

sotiris@jumbo:~$ host 2001:db8:2:2001::11
Host not found: 3(NXDOMAIN)

The zone for your /32 is

$TTL 1d
@    IN    SOA ( 42 1h 15m 30d 10m )
     IN    NS    localhost.
;    IN    NS    localhost. ; delegate 2001:db8:2:2001/64

The zone for your /64 is

$TTL 1d
@    IN    SOA ( 42 1h 15m 30d 10m )
     IN    NS    localhost.
; IN PTR mydevice.local.

Reconfig and run host again

sotiris@jumbo:~$ host 2001:db8:2:2001::11 domain name pointer mydevice.local.

GeoDNS with BIND

Είχα γράψει και παλιότερα για λύσεις «GeoDNS» αλλά σήμερα βρήκα ακόμα ένα patch για το BIND (9.5 και 9.6) που κάνει αυτή τη δουλειά.. Είναι στο git του;a=summary

Υπάρχει πια δικιολογία για να μη γίνεις η «Akamai» για τα services του δικτύου σου;


BIND Dynamic Update DoS

  • Summary: BIND denial of service (server crash) caused by receipt of a specific remote dynamic update message
  • Versions affected: BIND 9, all versions
  • This vulnerability affects all BIND servers which serve at least one DNS zone authoritatively, as a
    master, even if dynamic updates are not enabled.
  • Exploitable: remotely (An active remote exploit is in wide circulation at this time. Please upgrade immediately!

ISC Announcement:

munin plugin to monitor dns response times

A munin plugin that allows you to monitor the response time of any DNS that allows you to recurse.

dnsresponse_ — it’s a poor man’s smokeping DNS probe :)
( does not allow arbitrary file uploads, so grab it from munin-exhange)

To install it, place it in /usr/share/munin/plugins/ and run «munin-node-configure –shell«.

By default it graphs the Average, Median and StdDev of 20 DNS queries.

sample dnsresponse_ graph
sample dnsresponse_ graph

Resolvers vs. Authoritative DNS

Γιατί στην Ελλάδα (σχεδόν) όλοι πιστεύουν ότι οι DNS που πρέπει να έχουν στη σύνδεσή τους είναι αυτοί που έχει δηλώσει ο ISP τους για το κύριο domain name του; Είναι ένας μύθος που δεν ισχύει..

Μάλλον γιατί μέχρι τώρα, όλοι οι ISP έδιναν στους πελάτες τους τους ίδιους Name Servers και για τη σύνδεσή από το σπίτι, και για τα domains που έκαναν Register..

Κάποιοι έχουν έναν physical server με δύο διαφορετικές virtual IPs από το ίδιο LAN..

Περισσότεροι έχουν δύο physical servers στο ίδιο Data Center..

Λιγότεροι έχουν δύο ή παραπάνω physical servers σε διαφορετικά Data Centers σε διαφορετικές πόλεις..

Συνήθως λοιπόν, οι ISPs, αφού έμπαιναν στον «κόπο» να φτιάξουν και να διαχειριστούν αυτή την υποδομή από DNS Servers, τους χρησιμοποιούσαν και για τους access πελάτες (pstn, isdn, adsl) αλλά και για τα domain hostings.. Και το recursive DNS ήταν ανοιχτό για όλους, από όπου κι αν ερχόταν το request..

Ομως σιγά σιγά τα πράγματα αλλάζουν.. Εμφανίζονται Amplification Attacks.. Τα νούμερα (domains + χρήστες) μεγαλώνουν.. Η κίνηση εκτοξεύεται (από χιλιάδες queries σε εκατόμύρια)..

Για να αντιμετωπίσουν τα attacks σιγά σιγά οι ISPs αρχίζουν και κλείνουν το recursion στους μη-πελάτες τους (το αντίστοιχο του open-relay για το email).. Τώρα φτάσαμε στο σημείο που ούτε καν τα αποτελέσματα της cache που έχει ένας DNS δε σου δίνει, εκτός κι αν είσαι πελάτης..

Μετά αρχίζουν να πουλάνε πακέτα web hosting με control panels (plesk, cpanel κλπ).. Και σαν μέρος του control panel, περιέχεται και το DNS του Domain.. Αντί να κάνουν Integration του control panel με τους DNS servers που ήδη έχουν, δίνουν τον DNS του control panel.. Κι έτσι αποκτάνε και άλλο set από DNS servers, ειδικά για domains που γίνονται hosting στο control panel..

Μετά εμφανίζεται το Κάποιοι χρήστες αρχίζουν να αλλάζουν από μόνοι τους τους DNS Servers στη σύνδεσή τους και αγνοούν αυτούς που τους δίνει ο ISP..

Και τέλος, εμφανίζονται ISPs που, επιτέλους, αρχίζουν να δίνουν άλλους DNS στους access πελάτες τους από αυτούς που χρησιμοποιούν για τα domains τους (The importance of separating DNS caches from DNS Servers)..

2011 Update: Resolvers Vs. Authoritative DNS, Part 2