It’s a few days over 30 since I tinkered with DNSSEC and wrote my previous blog entry on the subject.

I played for a couple of days, got it working, blogged it, and then, of course, totally forgot about it while other stuff filled my mind and time.

Until today.

Today, it turns out, is 30 days since I last updated the zonefile, and the last time I signed it.

So, today, the RRSIGs expired, and anything that’s doing DNSSEC started failing when resolving it.

So, I’ve knocked up some quick and dirty monitoring that runs from cron on the primary.

First, there’s a shocking bit of shell that decides if the zone has any records with RRSIGs about to expire, and if there are, re-signs the zone and issues an rndc reload.

As an aside, I’d previously used -N INCREMENT in the signzone command. The meant I’d have to open the original zone, and modify it. For the automatic re-signing, I’ve changed this to UNIXTIME so that no modifications are required to the unsigned zone. I’d previously used a serial number format of YYYYMMDDXX, and so swapping to UNIXTIME meant a quick visit to the secondaries to persuade them to transfer the zone, but all should be working well now.

The way the shell decides if the zone has expired or about to expire RRSIGs is by calling a bit of perl that opens the zonefile, and hauls through it looking at the RRSIG expiry timestamps.

The scripts output nothing if all is well, and something useful if not. It’s designed to run from cron, once per day, and so cron will email me if there are problems, and won’t bother me if all is well.

It’s a bit rough and ready, but functional.

ToDo:

• Make it less rough. I’ve been lazy, and so used shell for the shell’y kind of bits, and perl for hunting around regexp style in the zonefile. On the upside it took minutes to write and test.
• Package it into a perl module?
• Somehow automate hunting for zones that are signed and checking them. Whoring round /var/cache/bind looking for *.signed is quick, but probably a bit hacky?

Tags: BIND,DNS,DNSSEC
Categories: Technical
No Comments »

The internet has a defined set of rules known as RFCs. They work together to make sure that all participants of the internet community are working in the same way, and that the things they do as part of that community will work with, and interact correctly with the things that others do.

RFC1035 section 4.2.1 (UDP Transport) states:

Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header.

You then fall back to TCP and repeat your query to get the full response.

Yes, AXFR queries are TCP, but not exclusively!

Assuming that, because you won’t be doing any transfers and therefore don’t need to allow tcp/53, is wrong, and will invariably involve you having issues with some service or other, due to not getting the correct information from DNS.

I’ll give you an example:

You use a service that, for whatever reason, decides that as a basic form of load balancing, to use multiple A records for the ‘name’ you’ve queried. So, you ask for www.example.com and, rather than give you back a single A record, they give you one for each of their servers. This could easily become longer than 512 bytes, the answer will be truncated, and you *should* repeat your request using TCP. Your computer knows this, and will automatically do it.

If you’ve blocked tcp/53 on your firewall, it’ll fail. You’ll sit, staring at your computer, thinking that www.foo.com has fallen over, failed in some way, when they have not. It’s not their fault that you’ve not followed the rules.

It’s not just website related records either, email related records (MX, or the TXT for DKIM, DomainKeys or SPF) are other great examples of this…. block tcp/53 from your mail server, and you could quite easily find yourself not receiving email from some senders.

[edited 18/3 at 15:00 to add the following]

Further reading (thanks to Duncan for the pointer) of RFC1123 section 6.1.3.2 (Transport Protocols) states:

DNS resolvers and recursive servers MUST support UDP, and
SHOULD support TCP, for sending (non-zone-transfer) queries.
Specifically, a DNS resolver or server that is sending a
non-zone-transfer query MUST send a UDP query first. If the
Answer section of the response is truncated and if the
requester supports TCP, it SHOULD try the query again using
TCP.

I guess I’m a little disappointed to see “SHOULD” instead of “MUST”, but given the document was written in 1989, I think today, it should be read as “SHOULD, if you want it to work”. It does go on to say:

Whether it is possible to use a truncated answer depends on the application. A mailer must not use a truncated MX response, since this could lead to mail loops.

Tags: DNS,Internet,RFC
Categories: Technology
1 Comment »