In April the National Board of Information Security Examiners released their US Cyber Challenge.  One of the questions during this quiz was about a packet capture of something related to DNS services.  While we can’t tell you whether or not the packet capture was truly a DNS zone transfer or not (legal stuff, we know), we do want to show you what a zone transfer looks like in both the logs and in a packet capture.  In this exercise, we will be looking at the transfer between 2 of our 6 BIND DNS servers located at 10.20.0.53 and 10.20.0.153.  Why those IP addresses?  Well, DNS runs on port 53 so we found it humorous to put our DNS servers there.

The Setup

We put the primary DNS server on 10.20.0.53 and made some changes to force a zone transfer. The important thing is we incremented the serial number so the slave server (10.20.0.153) would recognize a change and force a transfer.

Primary DNS Logs (10.20.0.53)

After the zone transfer happened, we took a look at the logs on the primary server.  For us, this is in /var/log/messages but it depends on what you set your logging location to (/var/named/data/named.run).  Here are the primary logs:

Jun 17 13:22:55 pluto named[5834]: client 10.20.0.153#37119: transfer of '0.20.10.in-addr.arpa/IN': AXFR started
Jun 17 13:22:55 pluto named[5834]: client 10.20.0.153#37119: transfer of '0.20.10.in-addr.arpa/IN': AXFR ended
Jun 17 13:22:56 pluto named[5834]: client 10.20.0.153#35805: transfer of 'check.the.log/IN': AXFR started
Jun 17 13:22:56 pluto named[5834]: client 10.20.0.153#35805: transfer of 'check.the.log/IN': AXFR ended
Jun 17 13:24:38 pluto named[5834]: client 10.20.0.153#42443: transfer of '0.20.10.in-addr.arpa/IN': AXFR started
Jun 17 13:24:38 pluto named[5834]: client 10.20.0.153#42443: transfer of '0.20.10.in-addr.arpa/IN': AXFR ended
Jun 17 13:24:38 pluto named[5834]: client 10.20.0.153#60368: transfer of 'check.the.log/IN': AXFR started
Jun 17 13:24:38 pluto named[5834]: client 10.20.0.153#60368: transfer of 'check.the.log/IN': AXFR ended

And here are the logs from the BIND specific logs:

client 10.20.0.153#59251: transfer of ‘check.the.log/IN’: AXFR started
client 10.20.0.153#59251: transfer of ‘check.the.log/IN’: AXFR ended
client 10.20.0.153#37119: transfer of ’0.20.10.in-addr.arpa/IN’: AXFR started
client 10.20.0.153#37119: transfer of ’0.20.10.in-addr.arpa/IN’: AXFR ended
client 10.20.0.153#35805: transfer of ‘check.the.log/IN’: AXFR started
client 10.20.0.153#35805: transfer of ‘check.the.log/IN’: AXFR ended
client 10.20.0.153#42443: transfer of ’0.20.10.in-addr.arpa/IN’: AXFR started
client 10.20.0.153#42443: transfer of ’0.20.10.in-addr.arpa/IN’: AXFR ended
client 10.20.0.153#60368: transfer of ‘check.the.log/IN’: AXFR started
client 10.20.0.153#60368: transfer of ‘check.the.log/IN’: AXFR ended

As you can see, the key difference between the two logs is that the main log specifies the time the transfer happened (always important when trying to debug issues or truly find out what happened).

Slave Logs (10.20.0.153)

Just because you see in the logs that the transfer started on the primary, you still might not have a working slave name server because of file permissions or various other permissions.  Therefore, you must check the logs on the slave as well to make sure the transfer actually happened.  The main logs in /var/log/messages look like this:

Jun 14 22:59:42 venus named[8653]: running
Jun 14 22:59:42 venus named[8653]: zone 0.20.10.in-addr.arpa/IN: Transfer started.
Jun 14 22:59:42 venus named[8653]: transfer of '0.20.10.in-addr.arpa/IN' from 10.20.0.53#53: connected using 10.20.0.153#42443
Jun 14 22:59:42 venus named[8653]: zone 0.20.10.in-addr.arpa/IN: transferred serial 1
Jun 14 22:59:42 venus named[8653]: transfer of '0.20.10.in-addr.arpa/IN' from 10.20.0.53#53: Transfer completed: 1 messages, 15 records, 368 bytes, 0.002 secs (184000 bytes/sec)
Jun 14 22:59:42 venus named[8653]: zone 0.20.10.in-addr.arpa/IN: sending notifies (serial 1)
Jun 14 22:59:43 venus named[8653]: zone check.the.log/IN: Transfer started.
Jun 14 22:59:43 venus named[8653]: transfer of 'check.the.log/IN' from 10.20.0.53#53: connected using 10.20.0.153#60368
Jun 14 22:59:43 venus named[8653]: zone check.the.log/IN: transferred serial 1
Jun 14 22:59:43 venus named[8653]: transfer of 'check.the.log/IN' from 10.20.0.53#53: Transfer completed: 1 messages, 19 records, 432 bytes, 0.002 secs (216000 bytes/sec)
Jun 14 22:59:43 venus named[8653]: zone check.the.log/IN: sending notifies (serial 1)

And the DNS specific logs look like this:

running
zone 0.20.10.in-addr.arpa/IN: Transfer started.
transfer of '0.20.10.in-addr.arpa/IN' from 10.20.0.53#53: connected using 10.20.0.153#42443
zone 0.20.10.in-addr.arpa/IN: transferred serial 1
transfer of '0.20.10.in-addr.arpa/IN' from 10.20.0.53#53: Transfer completed: 1 messages, 15 records, 368 bytes, 0.002 secs (184000 bytes/sec)
zone 0.20.10.in-addr.arpa/IN: sending notifies (serial 1)
zone check.the.log/IN: Transfer started.
transfer of 'check.the.log/IN' from 10.20.0.53#53: connected using 10.20.0.153#60368
zone check.the.log/IN: transferred serial 1
transfer of 'check.the.log/IN' from 10.20.0.53#53: Transfer completed: 1 messages, 19 records, 432 bytes, 0.002 secs (216000 bytes/sec)
zone check.the.log/IN: sending notifies (serial 1)

As you can see, the main difference is again the timestamps.

Packet Capture

Here’s the first batch of packets sent during the zone transfer:

We use high definition monitors here so we had to scale the picture down to fit on most screens.  Feel free to look at the whole thing, or even check out the entire Zone Transfer Packet Capture.  It’s only 29 packets so it shouldn’t be too difficult to look at.  Of course, if you have questions please don’t hesitate to let us know in the comments below.

Shameless Social Media Plug

Like what you see here?  Be sure to follow us on Twitter (@checkthelog) and Like us on Facebook.  We love interacting with our readers and helping them understand their logs.