Unable to completely transfer root zone

Tony Finch dot at dotat.at
Tue Feb 11 12:47:13 UTC 2020


Warren Kumari <warren at kumari.net> wrote:
> von Dein, Thomas <Thomas.vonDein at f-i-ts.de> wrote:
> >
> > Does anyone have an idea, what's wrong here and how I could possibly fix this?
>
> This sounds very much like a path MTU issue -- it starts the transfer,
> gets part of the way and then a big packet doesn't make it through...

I wondered about that, but a pMTU problem usually turns up right at the
start of bulk data transmission, and on the receiver side I would expect
to get approximately nothing rather than approximately 180 KB.

There are different zone transfer implementations in `named` and `dig` so
it's conceivable that they do something different enough to provoke a RST.
But I can't think of anything plausible that might cause a RST... could it
be IXFR vs AXFR? the logs didn't mention the flavour of transfer. Ah, but
they did say:

transfer of './IN' from 192.0.47.132#53: resetting

which can happen when an IXFR fails and `named` tries to fall back to
AXFR. (The relative priorities of the log messages in this area could be
improved, because the LOG_DEBUG(3) "got %s, retrying with AXFR" is much
more informative than the LOG_INFO "resetting"...)

So maybe try setting `request-ixfr no;` and see if that improves matters.

(IXFR does not provide many advantages for the root zone because most of
the update traffic is bulk re-signing of the zone for which IXFR is very
inefficient.)

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Viking, North Utsire, South Utsire: Westerly veering northwesterly 6 to gale
8, occasionally severe gale 9 at first except in North Utsire. Very rough or
high. Wintry showers, thundery for a time. Moderate, occasionally poor.


More information about the bind-users mailing list