CNAME problems

[Sam Wilson]

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