CNAME problems
Sam Wilson
Sam.Wilson at ed.ac.uk
Wed Jul 7 09:15:50 UTC 1999
In article <199907062327.JAA00720 at bsdi.dv.isc.org>, Mark_Andrews at isc.org wrote:
>> [ Steinar Haug and Murray Walker discussed responses for ANY queries
>> for cstr.ed.ac.uk which were >512B and the fact that one of its
>> secondaries, xlab-0.ed.ac.uk (sorry - I hate the word "slave"), was
>> still returning big answers even though the data on the primary had
>> been modified. Steinar suggested that the SOA serial number had not
>> been updated. I wrote... ]
>>
>> As the hostmaster of xlab-0.ed.ac.uk I'm not sure how it can be returning
>> (as it apparently is) a UDP answer >512 bytes. It's running the same
>> software (BIND 4.9.7 - due an upgrade shortly) as other servers which are
>> secondaries for cstr.ed.ac.uk. Any ideas? It's due to get an ndc restart
>> shortly so if the answers aren't quick the evidence may be gone.
>>
>
> It is *not* reporting an answer bigger that 512 bytes via UDP.
> All BIND based resolver libraries have supported TCP retry since
> at least the BIND 4.8 days. You have to take special steps to
> stop it retrying via TCP. Note the +ignore (ignore truncation
> errors) on the dig command below.
I thought I had prevented TCP retries with the +novc option to DiG,
however looking at the DiG output (DiG 2.1) shows that no option I
give it seems to be reflected in the "res options:" line. Using
your command line gives me exactly the same output as I get without
any +options at all. Is this a known problem with DiG 2.1 or have
I just got a duff copy?
(I've also often wondered what the "ignore" option was for, but
never bothered to look in the code. I was never sure why one
would ignore or observe truncation errors but I now infer that
normal operation of DiG is to observe a TC flag and silently
retry with TCP without reporting anything; "ignore" means "ignore
the TC flag and just report the answer" - right?)
> BIND 8 introduced TCP retries into the server code.
Excuse my ignorance, but is this relevant to this part of the
debate or just to earlier parts (which I missed - I'm slightly
surprised that Murray Walker didn't take the problem up locally
before hitting the newsgroup). In this case we have DiG querying
a particular server directly about a zone it's responsible for -
no server retries involved.
> As for the different answers you have been told at least three
> times to increment the serial number for the zone.
Not me ref! Firstly I only incidentally saw this correspondence
yesterday. Secondly I'm hostmaster at ed.ac.uk and run
xlab-0.ed.ac.uk; we are only secondary for cstr.ed.ac.uk and can't
do anything about its serial number.
Thanks for your advice,
--
Sam Wilson
Network Services Division, Computing Services
The University of Edinburgh
Edinburgh, Scotland, UK
More information about the bind-users
mailing list