On 19-Oct-2015 7:29 PM Alexandre Chataignon wrote: > On 10/16/2015 07:52 AM, Craig McQueen wrote: > > I'm interested in this concept. I applied your patch to ConnMan 1.30, and > I've been testing it. > > > > In my testing with DNS queries using the Linux 'dig' utility, I found it > > returns > malformed responses. That is because the 'dig' query includes an additional > record (ARCOUNT=1), of type OPT (41). When your patch > send_response_A() creates the response, it just uses the total length of the > query (which includes the question and the additional record), but then sets > the ARCOUNT=0, so that doesn't account for a query that contains additional > records. So the response appears to have just one answer record of type > "OPT", followed by an additional 16 bytes of junk. > > > > So the response is malformed for any query that includes more than one > question, and more than zero additional records. > > > > I also note that this patch sends an A record response to any query, with a > link to the query name. But it doesn't make sense to send an A record > answer if the query wasn't an A record question. E.g. if the query is a PTR > (reverse lookup) question for 216.58.220.110, it doesn't make sense to > respond with an A record saying the IP address of 110.2200.58.216.in- > addr.arpa is 192.168.1.1. > > > > So the patch would need to be improved as follows: > > > > * Check that the query first question is for an A record, and only send an A > record if so. > > * Calculate the correct length of the query header and question record(s), > in order to position the answer in the correct location in the response. > > * Calculate the correct total length of the response. > > * Consider whether an "OPT" or other additional record should be > > copied into the answer > > * Consider how to handle a query with more than one question. > > Hi Craig, > > Thank you very much for your review. > > It's true, I haven't thought about more complex DNS requests than a simple > and unique A request (which works in majority of case). > > I will try to correct this and provide a new patch soon.
I've made some patches, which I'll send through shortly. They fix the above issues (except possibly the OPT additional record), and also deal with another issue: * Internal DNS queries on the loopback interface should be permitted. That allows the device itself to access DNS servers on the Internet, while blocking clients on tethered interface(s) from doing so. Patrik wrote: > A captive portal is easier to implement by setting a NAT rule that redirects > incoming connections to a desired port on the local x.x.x.1 tethering > interface. True, but: * Allowing DNS queries constitutes a potential side-channel of communication, which could be a security issue for some applications. It's arguable how important that is. * I also want the device itself to be accessible with some DNS name. e.g. (at minimum) my-device.lan, or serial-number.lan. The captive portal DNS idea is a simpler way to achieve that goal. What would you suggest as an alternative implementation of that functionality (that can simply serve ConnMan's latest tether IP address in response to my- device.lan)? > Once the captive portal stuff is cleared out, the redirecting NAT > rule for that host can be modified not to capture connections. It's much > simpler than having to rewrite DNS replies from ConnMan. Your patch > enforces captive portal implementation for each and every device all the > time, for sure other use cases include letting hosts through that have > completed the steps enforced by the captive portal. Good point. I will send through a patch that allows loopback interface to do normal DNS look-ups. That would partially address that (e.g. allowing a captive portal to provide an HTTP proxy server), but wouldn't be a complete solution (e.g. for a mail server). Patrik wrote: > Let's attack the captive portal situation by redirecting traffic from the > hosts to > local ports using netfilter. It's a much more elegant and modular solution > than > to modify DNS replies from ConnMan. You've nearly persuaded me. I'm still stuck on how I could alternatively implement the DNS serving of my-device.lan feature. Since I've already done some work on this, I'll go ahead and send my patches, while I understand they are unlikely to be incorporated into the mainline code. -- Regards, Craig McQueen _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
