Re: [knot-dns-users] migrating from bind to knot

Hi, I think I know some medicine for your broken XFR ;-) Try adding `no-edns: on` to the remote section of the MS primary server. It's an undocumented option for better interoperability with broken software. It seems the option is still needed :-/ Daniel On 8/3/21 11:11 AM, mj wrote: > Hi, > > Yes, I'm positive, and I've tried kdig on all three subdomains, and they all look fine: > >> root@knot:/var/lib/knot/zones# kdig AXFR sub3.company.com @1.2.3.4 >> ;; AXFR for sub3.company.com. > ....... regular zone records stuff, nothing strange >> ;; Received 1914 B (23 messages, 23 records) >> ;; Time 2021-08-03 11:07:54 CEST >> ;; From 1.2.3.4@53(TCP) in 48.9 ms > > I will check about the wireshark stuff later. > > MJ > > > On 03/08/2021 11:01, libor.peltan wrote: >> Hi MJ, >> >> the "trailing data" is quite a specific error. It means that the incomming DNS packet does not comply with standards in the way that it contains some garbage data after its end. >> >> Are you sure that you are not getting this error when trying with kdig? >> >> Could you try to capture the communication with Wireshark (better on the Knot side) and check the actual wire format of the packets? >> >> Libor >> >> Dne 03. 08. 21 v 10:53 mj napsal(a): >>> >>> On 03/08/2021 10:16, mj wrote: >>>> I am also asking my colleages about more details and perhaps logs from the windows side of things. >>> >>> New info from their side: >>> >>> On the windows 2019 side, the failing zone transfers are logged as "Successful zone transfers" >>> >>> So windows DNS is under the impression it all went fine... >>> >>> For the record: >>>>  knotc zone-retransfer >>> just gives the same refresh failed (trailing data), and refresh, remote prim_master not usable >>> >>> Ideas?