Hacker News Reader

Comment by peterthomassen | Hacker News Reader

> though this certainly applies to deSEC) it's strange to me how so many DNS services (free or paid) struggle to import simple Bind zone files,

In deSEC's GUI, when you add a domain, you can expand an "Advanced" section and paste your zonefile.

You can do the same via the REST API using the "zonefile" parameter in your request.

> often either giving a vague error ("one or more records could not be imported"),

When there's an issue, the response will tell you which line it was. Perhaps that can be improved - we'd appreciate feature requests about that.

> just silently omitting records

We omit records that we manage ourselves, that is: SOA, NS, DNSKEY, RRSIG. Everything else is retained, and in fact deSEC has unusually broad record type support (see https://desec.readthedocs.io/en/latest/dns/rrsets.html#recor...).

(Disclosure: I'm CTO at deSEC.)

View on HN

A problem there is needing to temporarily delete the entire domain just to update using a zone file. I don't manage the DNS for anything remotely critical, but if I did, it would be unacceptable. Either way, the workflow feels deeply incorrect (though most users likely will use the record editor or the API instead; even I'd use the API through DNSControl, now).

Logging back into deSEC right now, it seems like the parser does work better than it used to, but TTL inheritance is still spotty. As an extreme example, the following input:

    @   7777 IN SOA  x. x. 1 9999 9999 9999 9999
                A    203.0.113.1
        4444    AAAA 2001:db8::1
    www         A 203.0.113.1

... correctly gets parsed by BIND (with the addition of a dummy NS record) as:

    @   7777 IN A    203.0.113.1
    @   4444 IN AAAA 2001:db8::1
    www 4444 IN A    203.0.113.1

... but deSEC parses:

    @   9999 IN A    203.0.113.1
    @   4444 IN AAAA 2001:db8::1
    www 9999 IN A    203.0.113.1

... where 9999 is a $TTL value from a different zone file, from a different domain, that I'd imported in a completely different session. The value is permanently (?) stuck to the entire account. This is ultimately almost a squabble since there's simple workarounds, but it did affect me when I used deSEC, and it's the sort of problem that I constantly run into with other managed DNS services too.

Hopefully this helps in some way.

First, I guess it would be a good idea to report discontent about things feeling "deeply incorrect" to our issue tracker. Just lamenting about the state of things won't change it.

Unless I happen to swing by. -- We use dnspython for zone parsing, and it turns out that this is legacy (pre RFC 2308) behavior implemented there. You could say it's a bug there. We've created a patch: https://github.com/rthalley/dnspython/pull/1300 When it gets merged, we'll update our API to use the new TTL inheritance mode (tracked at https://github.com/desec-io/desec-stack/issues/1262).

Call me cynical, but I've long stopped taking the time to report minor edge case bugs if I can't also provide a solution or patch, as such reports usually get ignored or sit at the bottom of a bugtracker forever. I likely didn't realize that deSEC was a FOSS stack at the time, or I might have looked into the zone file parsing further.

As for the zone file based workflow requiring zone deletion/recreation, perhaps a report/discussion would have led to something, but I was in the middle of testing managed DNS providers to get rid of my BIND servers and I didn't have any investment in deSEC, so it didn't occur to me to take the time. My initial post on here was less lamentation and more conveying personal experience to (possibly) save someone else some time.

In any case, none of these things were showstoppers for me (I went to another (paid) provider because I need very short TTL on some records for testing purposes), but I'm glad you took the time to look into the parser; it almost certainly will benefit others.

You're welcome!

Reply on news.ycombinator.com