Regarding DNSSEC, I was asked privately about that by two different persons, so perhaps I'll write the answer here for the benefit of everyone. If you're not into computer science, feel free to stop reading this message now.
DNSSEC's primary use case is to prevent DNS hijacking. With DNSSEC, validating DNS resolvers can check that there's a valid chain of signed zones, starting from root ., then on to .com and finally to .eurobilltracker.com. If there's a mismatch in the signatures somewhere along the path and a validating resolver is in use, the queried address will not resolve to an IP address. Because .com's records indicate that .eurobilltracker.com is signed, any responses from a malicious name server that pretends to be eurobilltracker.com's name server will be ignored because the malicious persons can't generate the correctly signed data themselves.
In all honesty, this has not been a real threat to us. I implemented this primarily because of academic interest. The tools for this are rather good nowadays. Automating everything and figuring out the proper timing for key creation/publishing/activation/revocation/deletion were the parts that required the most thinking. But I'm happy now -- most everything in this is automated, I only have to update the key signing keys to the registries manually once a year. The next time I need to update the KSKs is at the end of the year. If I'm feeling nerdish enough I may automate this step as well. I looked briefly at Gandi's documentation about this, and it seemed fairly straightforward. Zone signing keys are created and installed automatically every three months. Some sources say to create the ZSKs every month, but as I felt there's no particular threat, I'm creating those only every three months to reduce some complexity and to reduce some DNS traffic. When keys are being changed, two of them are active at the same time for a period of time, and it increases the size of the DNS responses. As of now, DNSSEC Visualizer
shows that there are two ZSKs, one in use (id 33435) and the other (id 45666) waiting to be activated. Tomorrow the zone will be signed by both of the keys, and on 6th April the zone will be signed with only the new key, and on 8th the old key will be removed. Here's a screenshot of the current situation:
I had done the work for my own personal domains before this, and making eurobilltracker.com DNSSEC-enabled required only creating the keys, publishing the KSK in .com zone and adding eurobilltracker.com to my list of automatically managed zones.
Of course there are also some disadvantages. If some script I use does not work properly, it will cause eurobilltracker.com to become unreachable for those users using a validating DNS server. If you want to know if the DNS server you are using validates the responses, go to DNSSEC Resolver Test
and press the "Start test" button. Another disadvantage is that DNSSEC increases the size of the responses, causing more DNS traffic. Some DNS servers can also be used for DDoS by creating requests from a forged source address, and having DNSSEC enabled makes those responses sent to an innocent victim bigger. Therefore I'm limiting the amount of responses per IP address to some sane amount to make EBT's name servers less interesting for DDoS purposes.