- Sep 23, 2014
-
-
Jan Kadlec authored
-
Jan Kadlec authored
-
- Sep 19, 2014
-
-
Jan Kadlec authored
-
- Sep 18, 2014
-
-
Marek Vavruša authored
Conflicts: src/common/namedb/namedb_lmdb.c src/common/namedb/namedb_trie.c
-
Jan Kadlec authored
-
- Sep 16, 2014
-
-
Jan Kadlec authored
-
Jan Včelák authored
Events cleanup See merge request !286
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
- events.c: event manipulation API - events-impl.c: zone event implementations - events-replan.c: event replanning implementations Closes #262
-
- Sep 15, 2014
-
-
Daniel Salzman authored
Knotc doc See merge request !285
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Daniel Salzman authored
knotc: dynamic buffer for response See merge request !284
-
Jan Včelák authored
closes #298
-
- Sep 12, 2014
-
-
Jan Kadlec authored
-
Daniel Salzman authored
Additional nsec null checks See merge request !283
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
fix race during server reload closes #296 See merge request !281
-
Jan Včelák authored
refs #296
-
Jan Včelák authored
refs #296
-
- Sep 11, 2014
-
-
Jan Včelák authored
closes #293
-
- Sep 10, 2014
-
-
Marek Vavruša authored
Axfr ixfr client See merge request !280
-
Jan Kadlec authored
-
- Sep 09, 2014
-
-
Jan Kadlec authored
-
Jan Kadlec authored
-
Jan Kadlec authored
This reverts commit e774c8a8.
-
Jan Včelák authored
-
Marek Vavruša authored
IXFR: falback to AXFR master-side fix When Knot master replied to IXFR query by AXFR-style IXFR, the response was wrong in two ways: 1. Header was cleared: no ID, no QR flag 2. QTYPE was changed to AXFR Both are wrong. The header must be set properly and the IXFR QTYPE must be preserved even if the response has the AXFR format (that's the way to distinguish it), see [RFC1995, Section 4](http://tools.ietf.org/html/rfc1995#section-4). I removed these changes to the packet. But I'm not totally sure that there is no problem now, because the packet-processing is too obscure. @mvavrusa should review this definitely. Tests pending. See merge request !278
-
Lubos Slovak authored
-
Jan Kadlec authored
-
Lubos Slovak authored
-
Jan Kadlec authored
-