nobody's soup

I noticed .de domains were not resolving as expected. While debugging, it turns out some DNS servers of the denic seem to be out of sync.

This is a ``nice" query, created by resolving a well known domain on the denic nameservers:
---snip---
nihilus@zeus:~$ dig -t NS de

; <<>> DiG 9.5.1-P3 <<>> -t NS de
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61752
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 9

;; QUESTION SECTION:
;de.                IN    NS

;; ANSWER SECTION:
de.            86400    IN    NS    z.nic.de.
de.            86400    IN    NS    c.de.net.
de.            86400    IN    NS    l.de.net.
de.            86400    IN    NS    a.nic.de.
de.            86400    IN    NS    s.de.net.
de.            86400    IN    NS    f.nic.de.

;; ADDITIONAL SECTION:
a.nic.de.        2191    IN    A    194.0.0.53
a.nic.de.        2191    IN    AAAA    2001:678:2::53
c.de.net.        2191    IN    A    208.48.81.43
f.nic.de.        2191    IN    A    81.91.164.5
f.nic.de.        2191    IN    AAAA    2001:608:6:6::10
l.de.net.        2191    IN    A    77.67.63.105
l.de.net.        2191    IN    AAAA    2001:668:1f:11::105
s.de.net.        2191    IN    A    195.243.137.26
z.nic.de.        2191    IN    A    194.246.96.1

;; Query time: 819 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 12 14:50:27 2010
;; MSG SIZE  rcvd: 306

nihilus@zeus:~$ for i in a.nic.de c.de.net f.nic.de l.de.net s.de.net z.nic.de; do dig fefe.de @$i; done

; <<>> DiG 9.5.1-P3 <<>> fefe.de @a.nic.de
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9590
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;fefe.de.            IN    A

;; AUTHORITY SECTION:
de.            7200    IN    SOA    f.nic.de. its.denic.de. 2010051253 7200 7200 3600000 7200

;; Query time: 23 msec
;; SERVER: 2001:678:2::53#53(2001:678:2::53)
;; WHEN: Wed May 12 14:50:54 2010
;; MSG SIZE  rcvd: 77

[...]

; <<>> DiG 9.5.1-P3 <<>> fefe.de @z.nic.de
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40763
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;fefe.de.            IN    A

;; AUTHORITY SECTION:
de.            7200    IN    SOA    f.nic.de. its.denic.de. 2010051253 7200 7200 3600000 7200

;; Query time: 12 msec
;; SERVER: 194.246.96.1#53(194.246.96.1)
;; WHEN: Wed May 12 14:50:54 2010
;; MSG SIZE  rcvd: 77

---snip---

As you see, at least a.nic.de and z.nic.de return an NXDOMAIN for a registered and correctly configured domain.

with "listen-on-v6 { any; };" my bind9 instance binds correctly to all Ipv6 addresses. But as this is bad style - one does not bind services to all Ips, especially not a DNS server - and as it would even cause problems - I have a dnscache on ::1, bind9 is only authoritative - I want it to bind on a specific address. A "listen-on-v6 { 2001:123:1234::1/128; };" should do that. Hrm, after a restart of bind it does not listen on IPv6 at all.
I start up named with "named -g -d 5 -c /etc/bind/named.conf -u bind" for debugging. Here, bind9 binds nicely on the v6 address. So what is that initscript in debian doing different? Hrm, obviously it uses "-t /var/lib/bind" to chroot the named, which is probably a good idea as bind is relatively complex. But that can't have anything todo with IPv6, can it? Firing up "named -g -d 5 -c /etc/bind/named.conf -u bind -t /var/lib/bind" I was negatively stunned: It does have something todo with IPv6. There is no error message or something, it just does not bind on IPv6. For what reason, I can only guess.

Isn't that bind how we now and love it?

Today, I would like to thank Carlo Wood. Who's that you will probably think. He is the author of ext3grep. But first things first.

Everyone's (or at least my) homedir gets a little congestet from time to time and needs to be tidied up. As it goes, I once had a file 'bl.tex' for testing something and this file and all that get created during the run of 'pdflatex' were still lying around. So I typed 'rm bl.*' or at least I wanted to, instead I issued 'rm bl*'. One little dot, but a much larger effect. It happens that I had a file called blub.txt with some important content, and of course after that command, that file was gone.

Few seconds later, after I realized what I had done, I issued 'mount -o remount,ro /mnt/raid1' at my server. This is the volume where my homedir resides. This is important, as it stops writing to the filesystem. If writing would continue, the file might be overwritten or the journal would have lost the interesting parts. (Journal is involved in restore operation)

I probably could have used 'ext3grep /dev/mapper/storage-store --restore-file "home/nobody/blub.txt" however, as '/mnt/raid1' is a 750GB Volume, that would have taken some time. (I would have been willing to spend it, but as a nerd I of course wanted to have a faster way)

I did an "ls -li" in my homedir and discovered that the inode numbers of my files where more or less linear, probably because I recently moved my homedir by rsyncing it all to a new volume. I looked up the inode of the file lexically-before the first file deleted and the inode of the file lexivcally-after the last file deleted.

This way, I could be very sure that blub.txt had an inode somewhere between 10125947 and 10125958. Using

'for i in $(seq 10125947 10125958); do ext3grep /dev/mapper-storage-store --restore-inode $i; done'

I restored all those files deleted. Figuring out which of them was blub.txt was an easy task.

ps> 'ext3grep /dev/mapper-storage-store --ls --inode <inode of homedir>' would have probably shown the inode of 'blub.txt' too, but that would have taken some time on a 750GB volume.