So is it correct to assume that these DNSKEY's are unsafe to use?
The 512-bit ones definitely, because they can be factored within such a short time frame.
The 1024-bit ones should be safe because they are most likely Zone-Signing Keys (ZSKs) that are rotated once a month or so and getting brute-force cracking time of 1024-bit RSA keys down to less than a month is still very expensive.
Additionally, if a DNSKEY record has a (very) high time to live (TTL) for example a year, how would a high TTL impact DNSSEC security?
When rotating DNSKEY records you first introduce the new key into the zone, wait until every client has fetched the new key and no client has still the old one cached and then you can start using the new key. So if you have a year as your TTL for your ZSK you effectively can only rotate your ZSK once a year at most which is clearly undesirable.
Now if it is your key signing key (KSK) that has this long TTL you should be better off because these tend to use much longer keylengths (long-term secure ones) anyways. But as soon as you want to / have to rotate the ZSK you really want a "short" TTL.
If ECDSA is used, how long (compared to RSA) do the keys have to be in order to be secure for DNS record signing (a lower key length)?
2048-bit RSA keys offer roughly 112-bit security, thus a 224-bit curve (eg secp224r1) has roughly the same security. 1024-bit RSA keys offer roughly 80-bit security and thus a 160-bit curve (eg secp160r1) and for 512-bit keys we have about 40-bit security which would equal to an 80-bit curve size (of which I couldn't find any examples just now). For more details on these conversions, see keylength.com and this Crypto.SE answer. In practice only 256-bit and 384-bit curves are standardized for DNSSEC.
The length of the ECDSA signature is always aboout two times the size of the curve here (encoding the x coordinates of two points). The size of an ECDSA public key is also roughly twice the curve size (unless compression is used).
What is the practical risk of a DNSKEY getting compromised?
Basically the same as with using no DNSSEC at all, because an attacker can forge records on their way from the authoritative server to potential recursive resolvers or the end user. The only caveat here is that said systems will still think that DNSSEC protects them and thus it will pass eventual "only-DNSSEC validated records) filter.
