On Dec 5 2013, Matthew Pounsett wrote:
On 2013-12-05, at 01:37 , Mark Andrews ma...@isc.org wrote:
Note, named will for the use of TCP in its UDP response.
s/for/force/
Always? Regardless of response size? Interesting. What's the rationale
for doing it that way?
Just to
On 2013-12-06, at 12:11 , Chris Thompson c...@cam.ac.uk wrote:
The sense in which BIND forces use of TCP is that when it gets an
IXFR request over UDP, it always just replies with the current SOA.
It doesn't bother to work out whether an incremental transfer is
possible and if so whether
In message 2e1626be-94f8-44e8-a73c-6521c44ba...@conundrum.com, Matthew
Pounsett writes:
On 2013-12-05, at 01:37 , Mark Andrews ma...@isc.org wrote:
Note, named will for the use of TCP in its UDP response.
s/for/force/
Always? Regardless of response size? Interesting. What's
I'm trying to debug an IXFR problem with a client, and using dig in its place
to compare IXFR requests between it and the misbehaving client. I noticed that
when I do an IXFR with dig it defaults to TCP rather than UDP. I tried forcing
it over with +notcp but I still get a TCP query.
From
On 2013-12-04, at 21:22 , Mark Andrews ma...@isc.org wrote:
The options are processed left to right so the +notcp has to be
after the ixfr=serial.
There are two reasons I don't understand why this is the case.
1) Since there is only one query in the command, I don't understand why left
to
In message c60198c7-b559-4e7d-bbcb-e3ba51687...@conundrum.com, Matthew
Pounsett writes:
On 2013-12-04, at 21:22 , Mark Andrews ma...@isc.org wrote:
The options are processed left to right so the +notcp has to be
after the ixfr=serial.
There are two reasons I don't understand why this
6 matches
Mail list logo
