Simple answer: the tool is right, this is proper behavior for a volume texture.
Long answer: A volume texture is a 3D-texture in which mipmaps shrink in all three dimensions. So if you have a 16*16*16 texture, the next miplevel is 8*8*8, and then 4*4*4, etc, down to 1*1*1. If the dimensions aren't the same, then you still have each one (this is the same rule as for 2D textures). So 16*4*8 would have mips 8*2*4, 4*1*2, 2*1*1, and 1*1*1. You have something like 128*128*2, so the next miplevel is 64*64*1. Basically, there is only one 2D slice left to put the data, so it is a blend of the two.
This is like storing a pair of 1D lookup tables in a 64*2 2D texture. The next mipmap is 32*1, and so it can no longer distinguish between the two tables, and it is an average of the two.
What you want is a 2D texture array, for which the mipmaps for different layers are totally separate. If you have 6 layers in a 2D texture array, then you will have 6 1x1 images at the smallest miplevel, all guaranteed not to filter across layers. It looks like support for texture arrays in .dds files is spotty at best. You might have to upload the data manually from a bunch of separate .dds files.