3 Srp
2021
3 Srp
'21
12:04
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?