- Sep 16, 2014
-
-
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
-
Lubos Slovak authored
- Response had the header cleared (no ID and no QR flag). - Also, the Question was wrongly set to AXFR. It should remain IXFR although the response is in AXFR format. (See RFC1995, Section 4)
-
- Sep 08, 2014
-
-
Daniel Salzman authored
-
Daniel Salzman authored
-
Jan Kadlec authored
-
Jan Kadlec authored
-
- Sep 07, 2014
-
-
Jan Kadlec authored
-
- Sep 05, 2014
-
-
Daniel Salzman authored
-
- Sep 04, 2014
-
-
Jan Včelák authored
-