Size of zone transfers
Mark_Andrews at iengines.com
Mark_Andrews at iengines.com
Tue Nov 2 23:38:55 UTC 1999
> We have been doing some testing of zone transfers between an 8.2.1 master
> (10.184.0.28) and an 8.2.1 slave (10.184.0.29) in a lab environment. We did
> the testing using a tool called NetXray on a laptop. All 3 devices were
> connected into a hub which was not connected to anything else.
>
> We transferred the zones by deleting the zone file on the slave and then
> running named-xfer from the command line.
>
> The results:
> zone 1:
> File sizes:
> - on master: 615000
> - on slave: 711821
> Data transferred over the wire:
> - packets: 1233
> - data: 1067506
> Records: 20549
>
> zone 2 had similar results. In both cases, the zone transfer was successful.
>
> The question was raised as to why there was such disparity between the data
> sizes. The difference between files on the master & slave is easily
> explained as the $TTL value is added to each record as the data on the slave
> is written. However the additional over the wire traffic is hard to
> determine.
Because you are most probably using the one answer format for zone
transfers. Switch to using "transfer-format many-answers;".
>
> Looking at the packet capture, the Net-Xray tool believes that there were a
> number or malformed or "errored" DNS packets in the capture. Looking at the
> packet contents, they had invalid names in the the Question part of the
> packet and a number of other errors. Retries of these would explain the
> disparity in data sizes.
My bet is Net-Xray can't properly decode the stream.
>
> I guess my question is - "is this normal?". If not, my only guess as to why
> it is occuring is insufficient hardware for the name servers - they are
> SPARC 5's doing nothing but DNS.
>
> Any ideas? I can post the packet captures if they would help.
>
> Cheers
>
> J.
>
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at iengines.com
More information about the bind-users
mailing list