<p dir="ltr">Just read the last few emails again. Your ISP may well be doing deeper inspection and blocking TCP-based DNS too.</p>
<p dir="ltr">I've just tried the following on one of my boxes:</p>
<p dir="ltr"> sudo dnsmasq -d -i* -p7821</p>
<p dir="ltr">and on another:</p>
<p dir="ltr"> dig -p7821 @myhost.tld <a href="http://google.com">google.com</a></p>
<p dir="ltr">and it worked fine.</p>
<p dir="ltr">If this works for you, please remember to set up port knocking. Or set up something sensible, like a VPN or tunneling over SSH.<br></p>
<p dir="ltr">Mark</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 14 Jul 2016 02:32, "Mark Steward" <<a href="mailto:marksteward@gmail.com">marksteward@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I'm not sure about that conclusion. The overwhelming likelihood is that your ISP is blocking UDP on port 53. This is very common on domestic ISPs, precisely to stop people shooting themselves in the foot by running open resolvers.</p>
<p dir="ltr">I've only skim-read this thread. Did you properly test listening on UDP 53 with nc -u -l53 or equivalent? Could you reach it from another machine on the internet? If not, that's your problem, not dnsmasq.</p>
<p dir="ltr">If you do convince your ISP to open up access, can I recommend you at least use port knocking to reduce the likelihood of being used by botnets? Honeypots demonstrate that an open service on IPv4 will often be picked up in hours.<br></p>
<p dir="ltr">Mark</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 14 Jul 2016 01:57, "T o n g" <<a href="mailto:mlist4suntong@yahoo.com" target="_blank">mlist4suntong@yahoo.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 10 Jul 2016 21:50:03 +0200, Albert ARIBAUD wrote:<br>
<br>
> Regarding running the DNS on TCP alone: problem is, you might force the<br>
> dig command to use TCP, but that's a specific case; all DNS resolutions<br>
> happening on your machine in any other process that dug will keep on<br>
> trying UDP first when the request size warrants it, because that's the<br>
> standard.<br>
<br>
That's not a problem for me. If I have to use TCP, then I'll always use<br>
`dig +tcp`, so UDP will never be in the way.<br>
<br>
> OK, so no blocking at your box level except for what fail2ban may decide<br>
> to block. Now we're faily sure your probelm is with either your ISP or<br>
> your hosting provider.<br>
<br>
After struggled for a few days, I finally decided that I should reply, to<br>
bring some closure on this. Thank you for all these days of your tireless<br>
help. However, my conclusion is still the same as my first post -- dnsmasq<br>
is unable to provide public DNS service -- It can be used as DNS server<br>
for local host, or local network, but just not for the general public.<br>
We've ruled out everything possible, and the only thing left is dnsmasq.<br>
<br>
I.e., if there is any probelm with my ISP or my hosting provider, I<br>
wouldn't have been able to start a working second SSH session listening<br>
to port 53 (instead of 22).<br>
<br>
In other words, all else the same, swap in SSH to listen to port 53, it<br>
works; swap in dnsmasq, and it fails. With all else the same, dnsmasq is<br>
the only problem.<br>
<br>
Thanks anyway for all your helps.<br>
<br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div></div>
</blockquote></div></div>