On 02/19/2014 01:05 PM, Alan Bateman wrote:
On 18/02/2014 12:45, Florian Weimer wrote:
Thanks for the bug number and these suggestions. The new version is
here: <http://fweimer.fedorapeople.org/openjdk/8035105/>
I had to adjust the checked exceptions, so I wrapped the
InvalidNameException from DnsName in a CommunicationException as well.
I eliminated the recursion and from the name parser and added yet
another check for invalid label types. (Other implementations treat
extended label types as errors as well, so there is no need to
implement them here.)
Is this code actually used? (I discovered it because I looked at
DatagramSocket users in the JDK.) If it is, there are some other
fixes besides the ArrayIndexOutOfBoundsException handling that would
make sense.
Thanks for the update.
It's good to replace the recursion. Do you have the regular label case
right? It looks like the type is being used by the length.
It's encoded as a bit field, like this:
0000 0000 end of name
00xx xxxx regular label of length xxxxxx
11yy yyyy upper 6 bits of a compression reference
(followed by another byte containing the lower 8 bits)
01zz zzzz used to be invalid, then extended type, then invalid again
10zz zzzz invalid
I could rename the variable to typeAndLength.
> Also is it
necessary to catch InvalidNameException at line 363 as I don't think
this is throw anymore.
It is thrown by DNSName#add(int, String).
One thing about communication exceptions is that the DNS client will
retry. I think this is okay here but potentially it means that we fail
with too many compression references a number of times.
It's difficult to tell whether the old or new behavior is more
appropriate. If the packet is corrupted in transit for some reason,
even retrying the same server is helpful. Trying a different server
would be reasonable as well. The downside is that if there is a
consistent error in the data, then it takes a longer time until the
error is reported.
--
Florian Weimer / Red Hat Product Security Team
