On Fri, 2014-01-17 at 15:03 +0100, Peter Meerwald wrote:
>
> > This is indeed due to the DNS messge compression. Fixing this is a
> > little more complicated than anticipated. It's not only a matter of
> > updating the pointers after removing the domain part from the reply
> > whenever a short form like 'www' is requested; it's also handling
>> any pointers that can point to the now removed domain part. With a
>> protocol around for ~30 years already, we can surely bet on every
>> weird protocol aspect being used.
>
> I've proposed some patches for DHCP domain search options which also
> uses the DNS message compression, code posted here:
> https://lists.connman.net/pipermail/connman/2013-September/015778.html
This must have been lost somewhere I guess. Could you resend that one?
The DNS problem is a little bit more nasty than just uncompressing the
strings. The problem starts with an application asking for 'www' and
ConnMan receiving an ok response for www.somedomain.com because it
appended the (search) domain to the query. Now when the reply needs to
be passed back to the application, the .somedomain.com part needs to be
removed or else the reply is not accepted. While doing so, some of the
compressed parts can point to somedomain.com and needs to be properly
handled...
> is there a simple test case for the DNS problem? how to reproduce?
Not really, I have a nasty internal DNS that does string compression but
I don't think I can post the name lookup information from our internal
network publicly. Anything where 'host <hostname> 127.0.0.1' complains
about a bad packet is a good candidate.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
