[Dnsmasq-discuss] dnsmasq to provide public DNS service
T o n g
mlist4suntong at yahoo.com
Sat Jul 9 17:17:45 BST 2016
On Sat, 09 Jul 2016 12:30:26 +0200, Albert ARIBAUD wrote:
>> >> > Once we have netcat available on both ends, we will be able to
>> >> > mimic DNS exchanges between the machines but without dnsmasq being
>> >> > involved;
>> >> The connect is not the problem. I've stopped dnsmasq temporarily and
>> >> start SSH listening to port 53 and I was able to connect from home.
>> > The SSH test only proves you can access the box on TCP port 22
>> > (assuming you're usign the defaults) from your home; this does not
>> > prove anything regarding TCP port 53 or UDP port 53, which are what
>> > DNS uses.
>> > So:
>> > 1. Open a terminal and start an SSH session to your box. In this
>> > session, disable dnsmasq then run
>> > netcat -u -l -p 53
>> > 3. On your home machine open one terminal and run
>> > netcat -u xyz 53
>> > where xyz should be replaced with the public IP of your box.
>> > 4. Type some text then hit the Enter key on your home machine.
>> > Does your box display the text?
>> > 5. Type some other text then hit the Enter key in the shell to your
>> > box. Does the netcat running locally display the text?
>> Sorry for responding late, because I didn't get anything from the
>> server, my box. However, I did started a second SSH session before, to
>> listen to port 53 instead of 22, and it worked before. Then I looked
>> up... Long story short,
>> If I start `netcat -t` then it works; if I start `netcat -u` then it
>> doesn't work.
> ... and this shows why it is important to run the tests exactly as
> requested, rather than assume result from other tests...
>> I.e., the hosting company is blocking the UDP accesses.
> ... but again, do not jump to conclusions, t least not without further
> testing: ...
I'm quite positive it's my hosting company, but agree, will use more
testing to prove that.
>> But my dnsmasq does listen to TCP port as well though:
>> $ netstat -lnp | grep :53 (Not all processes could be identified,
>> non-owned process info
>> will not be shown, you would have to be root to see it all.)
>> tcp 0 0 0.0.0.0:53 0.0.0.0:*
>> LISTEN -
>> tcp6 0 0 :::53 :::*
>> LISTEN -
>> udp 0 0 0.0.0.0:53 0.0.0.0:* -
>> udp6 0 0 :::53 :::*
>> Will TCP only without UDP not OK?
> (someone correct me if I'm inexact here) DNS uses UDP port 53 as long as
> the request and response can fit in a single UDP datagram (packet), and
> will switch to TCP if a single UDP datagram is not big enough. I do not
> know, and do not think, that you can run a DNS server over a TCP port
That's actually even better. I mean, I don't care whether it UDP or TCP,
as long as it can resolve names, I'm happy. If the general public can't
use it except me, then it is even better.
So, let's forget about UDP, and focus on TCP instead. As long as I can
achieve the following, I'm happy:
$ dig +tcp +short cnn.com @22.214.171.124
>> I tried,
>> dig +tcp +short cnn.com @mybox, and will get:
>> ;; communications error to mybox_ip#53: connection reset
>> from my home or,
>> ;; communications error to mybox_ip#53: end of file
>> if trying from within my box.
>> Why is that?
> Let's first tackle the second one (box to box), as it does not involve
> your ISP and hosting provider networks, and therefore points at a purely
> local (configuration?) problem on your box.
> 1. Preamble: make sure dnsmasq is running.
> 2. Run a default (UDP) dig request. What does it output?
$ dig +short cnn.com @localhost
$ dig +tcp +short cnn.com @localhost
$ dig cnn.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> cnn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56353
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;cnn.com. IN A
;; ANSWER SECTION:
cnn.com. 65 IN A 126.96.36.199
cnn.com. 65 IN A 188.8.131.52
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 09 16:14:34 UTC 2016
;; MSG SIZE rcvd: 68
> 3. What does iptables-save display?
$ sudo iptables-save
# Generated by iptables-save v1.6.0 on Sat Jul 9 16:08:46 2016
:INPUT ACCEPT [990:208464]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1019:100580]
:f2b-sshd - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -p udp -m udp --dport 68 -j ACCEPT
-A f2b-sshd -j RETURN
# Completed on Sat Jul 9 16:08:46 2016
I believe this is the standard setting from fail2ban because I have
fail2ban_0.9.3-1 installed (and nothing else related).
More information about the Dnsmasq-discuss