Problem with DHT11 and DS18B20 temperature sensors
There appears to be several DHT sensor Arduino libraries available:


niesteszeck/idDHT11
adafruit/TinyDHT
adafruit/DHT-sensor-library


You might try an alternate library to see if that solves your current problem.  Note, some if not all of these libraries need to know which DHT model you are using.

Before going through the DHT and OneWire source code line by line looking for conflicts, try to narrow down what is causing the problem:


Try only instantiating the OneWire class and skip calling the read method within the class.


If this works, then the conflict likely resides in the OneWire read method and not in the OneWire initialization code (that is, the OneWire's Constructor).


Calling the DHT read method multiple times consecutively to see if the problem resolves it self.


Actually, you have done this and exposed a curious patter of good-bad-bad-good-bad-bad... which is worth looking into.  The point here is that if only the 1st call to the DHT read method after a call the the OneWire read method was bad, then there might be a setup problem in the DHT read method.


Call the DHT Destructor, the DHT Constuctor then make the call to the DHT read method every time you read the DHT sensor.


This is a test case only and an extreme measure.  What you are doing here is re-initializing the DHT library (driver) every time you use it.  If this works it points to an initialization problem where the DHT library is initialization something which should probably be re-initialized again inside the DHT read method.  As the OneWire library is using the same "something" (resource).

One last thing, the OneWire example I looked at here:
PaulStoffregen/OneWire
...did not use the DallasTemperature library.  I doubt this will make a difference, but it is usually best to keep your code simple and avoid unnecessary complexities.

Added later...

As pointed out in the comments, it turns out the DHT11 only takes new readings every few seconds.  Guessing, the DHT11 library you are using either knowingly returns an unreasonable value of -999.0 until this time passes.  Or is returning exactly what the DHT11 reports which, again, is an unreasonable value of -999.0.  

In this DHT11 library, there is code:

boolean DHT::read(bool force) {
  // Check if sensor was read less than two seconds ago and return early
  // to use last reading.
  uint32_t currenttime = millis();
  if (!force &amp;&amp; ((currenttime - _lastreadtime) &lt; 2000)) {
    return _lastresult; // return last correct measurement
}


...which returns the last good value for 2 seconds after a DHT11 "real reading" should the library user call upon it faster then the DHT11 can respond.