Minor com.sun.jndi.dns cleanup

Florian Weimer fweimer at redhat.com
Wed Feb 19 12:56:10 UTC 2014


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



More information about the core-libs-dev mailing list