11 Led
2014
11 Led
'14
8:42
Hi Anand,
Never mind. I understand your situation.
Initially, we had just timestamps in zone dumps. I prefer this, since
it makes smaller dumps and it is faster to process such records.
Afterwards,
we turned it off due to incompatibility with Bind. Because Bind is
unable
to load these dumps if you need it.
Is there still anybody who requires human-readable timestamps in zone
dumps from Knot?
If not, we probably disable this functionality.
Thanks,
Dan
On 2014-01-10 23:08, Anand Buddhdev wrote:
On 10/01/2014 19:42, daniel.salzman(a)nic.cz wrote:
We have probably found the problem. The function
gmtime, which we use,
is not thread safe. So I have replaced it with a better one. Please,
try the attached patch.
Hi Daniel,
Thanks for this. However, I prefer not to test this on our current Knot
servers, as they are running in production. I have applied Marek's
earlier patch which disabled human-readable timestamps, and that's
keeping this problem away.
Actually, I even asked Marek why you convert the timestamps to
human-readable in the zone dumps. After all, the zone files are only
going to be read back in by Knot, so you'd save some cycles when
writing
and reading the zones, by not converting them back and forth between
human-readable and unix timestamp.
Is it reasonable to ask that you just dispense with human-readable
timestamps?
Regards,
Anand 
13 Led
13 Led
11:27
New subject: 1.4.0 dumping zones with non-existent dates
On 11/01/2014 08:42, daniel.salzman(a)nic.cz wrote:
Hi Daniel,
Initially, we had just timestamps in zone dumps. I
prefer this, since
it makes smaller dumps and it is faster to process such records.
Afterwards,
we turned it off due to incompatibility with Bind. Because Bind is unable
to load these dumps if you need it.
I opened a bug report for BIND9, and Mark Andrews' response was that
unix timestamps should never have been allowed in the RFC, because it
breaks compatibility with older software. I disagree with him. BIND can
dump zones with human-readable timestamps if it wants to, but it should
*read* both formats, as should any software that claims to be RFC
4034-compliant.
Is there still anybody who requires human-readable
timestamps in zone
dumps from Knot?
If not, we probably disable this functionality.
You have my vote for disabling human-readable timestamps in zone dumps.
Regards,
Anand
18:58
New subject: 1.4.0 dumping zones with non-existent dates
Anand Buddhdev wrote:
On 11/01/2014 08:42, daniel.salzman(a)nic.cz wrote:
Hi Daniel,
New releases of DNS software break compatibility with older software all
the time when they add support for new RR types. The DNS master file
format is not a stable interface.
If DNS servers wanted to maximize compatibility with older software when
dumping zone files in master file format, they would dump only the
well-known RR types from RFC 1035 in "presentation format", and any
other RR type in generic \# RFC 3597 encoding :-)
--
Robert Edmonds
edmonds(a)debian.org
Initially, we had just timestamps in zone dumps.
I prefer this, since
it makes smaller dumps and it is faster to process such records.
Afterwards,
we turned it off due to incompatibility with Bind. Because Bind is unable
to load these dumps if you need it.
I opened a bug report for BIND9, and Mark Andrews' response was that
unix timestamps should never have been allowed in the RFC, because it
breaks compatibility with older software. I disagree with him. BIND can
dump zones with human-readable timestamps if it wants to, but it should
*read* both formats, as should any software that claims to be RFC
4034-compliant. 
14:44
New subject: 1.4.0 dumping zones with non-existent dates
Hey Anand,
we have decided to keep the dump in human readable format for easier debugging.
It's easier to decode YYYYMMDDHHMMSS format than just the unixtime stamp. We will
still be able to read both formats though, because we would like to adhere to standards
even if we disagree sometimes :).
Ondrej
On 11. 1. 2014, at 8:42, daniel.salzman(a)nic.cz wrote:
Hi Anand,
Never mind. I understand your situation.
Initially, we had just timestamps in zone dumps. I prefer this, since
it makes smaller dumps and it is faster to process such records. Afterwards,
we turned it off due to incompatibility with Bind. Because Bind is unable
to load these dumps if you need it.
Is there still anybody who requires human-readable timestamps in zone dumps from Knot?
If not, we probably disable this functionality.
Thanks,
Dan
On 2014-01-10 23:08, Anand Buddhdev wrote:
--
Ondřej Surý -- Chief Science Officer
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@nic.cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
On 10/01/2014 19:42, daniel.salzman(a)nic.cz
wrote:
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users We have probably found the problem. The function
gmtime, which we use,
is not thread safe. So I have replaced it with a better one. Please,
try the attached patch.
Hi Daniel,
Thanks for this. However, I prefer not to test this on our current Knot
servers, as they are running in production. I have applied Marek's
earlier patch which disabled human-readable timestamps, and that's
keeping this problem away.
Actually, I even asked Marek why you convert the timestamps to
human-readable in the zone dumps. After all, the zone files are only
going to be read back in by Knot, so you'd save some cycles when writing
and reading the zones, by not converting them back and forth between
human-readable and unix timestamp.
Is it reasonable to ask that you just dispense with human-readable
timestamps?
Regards,
Anand
15:15
New subject: 1.4.0 dumping zones with non-existent dates
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 13/01/2014 14:44, Ondřej Surý wrote:
Hey Anand,
we have decided to keep the dump in human readable format for
easier debugging.
It's easier to decode YYYYMMDDHHMMSS format than just the unixtime
stamp. We will still be able to read both formats though, because
we would like to adhere to standards even if we disagree sometimes
:).
Okay, that's fine Ondřej. But please test the patch properly to ensure
it doesn't emit bad dates when dumping the zone.
Additionally, we noted that when Knot failed to load the zone because
of the bad date, it did not log this fact, and continued silently, so
my colleague who was looking at the logs could not figure out why this
zone wasn't being loaded and served even though it was in the
configuration. Logging of any errors pertaining to failure to load a
zone is very important to an operator.
Another thing to note is that when I ran "knotc memstats <zone>" for
this zone, then it complained about the bad date, but this should have
been logged in the main knot log file.
Regards,
Anand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLT9QIACgkQi+U8Q0SwlCtn3ACfSntZ35HiIccxtR/Nc0Xh1zyA
/SkAnjvhWNPG/YPRR/pF2r9dXNuT0GdN
=C6FN
-----END PGP SIGNATURE-----
3762
days inactive
3764
days old
4 comments
4 participants
participants (4)
-
Anand Buddhdev -
daniel.salzman＠nic.cz -
Ondřej Surý -
Robert Edmonds