Yes, we have liftoff!
Haha :-)
What quick and good help here on this mailinglist! *impressed*
Thank you, all!
MJ
On 03/08/2021 12:04, Daniel Salzman wrote:
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?
--
https://lists.nic.cz/mailman/listinfo/knot-dns-users
