Discussion:
[Dnsmasq-discuss] DNS - ICMP - Destination unreachable (Port unreachable) ?
Nikita N.
2015-05-12 17:35:33 UTC
Permalink
Hi All,
was wandering about those ICMP frames, which keep coming out always
right after every Dnsmasq responses.
What is their origin?
What is their purpose?

Just to be sure what I'm talking about, here how it happens:
1) client (192.168.2.2) -> gateway (192.168.2.1), DNS Standard query
about mylocalsite.com
2) gateway -> client, DNS Standard query response A 192.168.2.1
(Wireshark "Request in" pointer is to #1)
3) client -> gateway, ICMP Destination unreachable (Port unreachable)
(Wireshark "Request in" pointer is also to #1)

That ICMP frame has IPv4 section, Src: 192.168.2.2 (client), Dst:
192.168.2.1 (gateway)
But the ICMP section shows the opposite, Src: 192.168.2.1, Dst:
192.168.2.2
Whose UDP section, Src Port: 53 (53), Dst Port: 5xxxx

I googled around, and I can't see any ICMP echo ping preceding, so I
don't understand where those ICMP are from, and/what are their purpose.
Maybe are generated by Dnsmasq, as some kind of alternate DNS response?
Maybe are generated by gateway linux kernel, as some kind of standard
behavior?
Maybe are generated by the client software/web browser?

Thanks
--
Nikita N.
***@operamail.com
--
http://www.fastmail.com - The way an email service should be
Simon Kelley
2015-05-12 21:22:53 UTC
Permalink
The most likely reason is that something opens a UDP port and sends the
query, and then gives up, or gets an answer from somewhere else, and
closes the UDP socket. When the answer comes back, there's nothing
listening on the destination port, so the kernel generates the ICMP port
unreachable message.

My money would be a on Web browser.

Cheers,

Simon.
Post by Nikita N.
Hi All,
was wandering about those ICMP frames, which keep coming out always
right after every Dnsmasq responses.
What is their origin?
What is their purpose?
1) client (192.168.2.2) -> gateway (192.168.2.1), DNS Standard query
about mylocalsite.com
2) gateway -> client, DNS Standard query response A 192.168.2.1
(Wireshark "Request in" pointer is to #1)
3) client -> gateway, ICMP Destination unreachable (Port unreachable)
(Wireshark "Request in" pointer is also to #1)
192.168.2.1 (gateway)
192.168.2.2
Whose UDP section, Src Port: 53 (53), Dst Port: 5xxxx
I googled around, and I can't see any ICMP echo ping preceding, so I
don't understand where those ICMP are from, and/what are their purpose.
Maybe are generated by Dnsmasq, as some kind of alternate DNS response?
Maybe are generated by gateway linux kernel, as some kind of standard
behavior?
Maybe are generated by the client software/web browser?
Thanks
Nikita N.
2015-05-13 06:49:55 UTC
Permalink
Hi Simon,
thanks for the bet! :)
So if I'm understanding correctly, it is nothing related to Dnsmasq,
right?

By your opinion, what is the purpose of such a ICMP/UDP frame sent from
src port 53?
Is that some kind of alternate DNS mechanism?
Is that anything standard behavior?
Post by Simon Kelley
When the answer comes back, there's nothing listening on the destination port
I always see those ICMP at gateway side, so I guess the gateway must
have received at least that answer back.
Is that answer back supposed to be a simple UDP frame or another ICMP
frame?

Also, client and gateway are on different machines, loopback is not
possible, why I can't see neither the UDP/ICMP answer back, nor the
query?
How would I set Wireshark, to sniff out those 2 mysterious UDP frame?
--
Nikita N.
Post by Simon Kelley
The most likely reason is that something opens a UDP port and sends the
query, and then gives up, or gets an answer from somewhere else, and
closes the UDP socket. When the answer comes back, there's nothing
listening on the destination port, so the kernel generates the ICMP port
unreachable message.
My money would be a on Web browser.
Cheers,
Simon.
Hi All,
was wandering about those ICMP frames, which keep coming out always
right after every Dnsmasq responses.
What is their origin?
What is their purpose?
1) client (192.168.2.2) -> gateway (192.168.2.1), DNS Standard query
about mylocalsite.com
2) gateway -> client, DNS Standard query response A 192.168.2.1
(Wireshark "Request in" pointer is to #1)
3) client -> gateway, ICMP Destination unreachable (Port unreachable)
(Wireshark "Request in" pointer is also to #1)
192.168.2.1 (gateway)
192.168.2.2
Whose UDP section, Src Port: 53 (53), Dst Port: 5xxxx
I googled around, and I can't see any ICMP echo ping preceding, so I
don't understand where those ICMP are from, and/what are their purpose.
Maybe are generated by Dnsmasq, as some kind of alternate DNS response?
Maybe are generated by gateway linux kernel, as some kind of standard
behavior?
Maybe are generated by the client software/web browser?
Thanks
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
--
http://www.fastmail.com - Choose from over 50 domains or use your own
Albert ARIBAUD
2015-05-13 07:43:13 UTC
Permalink
Hi Nikita,
Post by Nikita N.
Hi Simon,
thanks for the bet! :)
So if I'm understanding correctly, it is nothing related to Dnsmasq,
right?
Right.
Post by Nikita N.
By your opinion, what is the purpose of such a ICMP/UDP frame sent from
src port 53?
Is that some kind of alternate DNS mechanism?
Is that anything standard behavior?
It is standard behaviour. ICMP(v4) is used as a signalling mechanism
alongside IPv4 (e.g. for 'unreachable host' notifications)
Post by Nikita N.
When the answer comes back, there's nothing listening on the destination port
I always see those ICMP at gateway side, so I guess the gateway must
have received at least that answer back.
Is that answer back supposed to be a simple UDP frame or another ICMP
frame?
ICMP is never used for application data; a DNS answer is always
through IPv4, either over UDP or TCP.
Post by Nikita N.
Also, client and gateway are on different machines, loopback is not
possible, why I can't see neither the UDP/ICMP answer back, nor the
query?
How would I set Wireshark, to sniff out those 2 mysterious UDP frame?
Ideally, running Wireshark on a dual-Ethernet machine inserted on the
client's wire. In less ideal cases, run an instance of wireshark or
tcpdump on the client and one on the server, capture to file with
both, then fire two wireshark instances on any machine, have each one
load a capture and compare them visually.

Amicalement,
--
Albert.
Nikita N.
2015-05-13 07:58:58 UTC
Permalink
Hi Albert,
thank you for your hints, I'm going to setup as you suggest, and see
what happens.
a DNS answer is always through IPv4, either over UDP or TCP.
TCP?? :)
Do you mean, I can send a TCP frame from port 53 to Dnsmasq with a DNS
query?
And I will receive a TCP frame from Dnsmasq with the DNS query response?
--
Nikita N.
Hi Nikita,
Post by Nikita N.
Hi Simon,
thanks for the bet! :)
So if I'm understanding correctly, it is nothing related to Dnsmasq,
right?
Right.
Post by Nikita N.
By your opinion, what is the purpose of such a ICMP/UDP frame sent from
src port 53?
Is that some kind of alternate DNS mechanism?
Is that anything standard behavior?
It is standard behaviour. ICMP(v4) is used as a signalling mechanism
alongside IPv4 (e.g. for 'unreachable host' notifications)
Post by Nikita N.
When the answer comes back, there's nothing listening on the destination port
I always see those ICMP at gateway side, so I guess the gateway must
have received at least that answer back.
Is that answer back supposed to be a simple UDP frame or another ICMP
frame?
ICMP is never used for application data; a DNS answer is always
through IPv4, either over UDP or TCP.
Post by Nikita N.
Also, client and gateway are on different machines, loopback is not
possible, why I can't see neither the UDP/ICMP answer back, nor the
query?
How would I set Wireshark, to sniff out those 2 mysterious UDP frame?
Ideally, running Wireshark on a dual-Ethernet machine inserted on the
client's wire. In less ideal cases, run an instance of wireshark or
tcpdump on the client and one on the server, capture to file with
both, then fire two wireshark instances on any machine, have each one
load a capture and compare them visually.
Amicalement,
--
Albert.
--
http://www.fastmail.com - The professional email service
Albert ARIBAUD
2015-05-13 08:11:51 UTC
Permalink
Bonjour Nikita,
Post by Nikita N.
Hi Albert,
thank you for your hints, I'm going to setup as you suggest, and see
what happens.
a DNS answer is always through IPv4, either over UDP or TCP.
TCP?? :)
Do you mean, I can send a TCP frame from port 53 to Dnsmasq with a DNS
query?
And I will receive a TCP frame from Dnsmasq with the DNS query response?
Generally speaking -- and I am not a specialist on DNS, so I may make
mistakes on the particulars -- DNS is supposed to function as follows:

- requests are made over UDP port 53.

- requests made over UDP are answered over UDP.

- answers made over UDP might be truncated for Many Reasons(tm) --
mostly because they should remain short enough to fit in a single
layer 2 (e.g. Ethernet) frame.

- if a truncated UDP answer was received, TCP port 53 might be used.

- requests over a TCP port 53 connexion are answered over that TCP
connection, of course.

See <http://tools.ietf.org/html/rfc1034> for the ugly details.

See also <http://tools.ietf.org/html/rfc1035> section 4.2 regarding UDP
vs TCP: you can do a DNS request over TCP, but note that TCP should
be the fallback method and UDP the preferred method, at least for
standard queries.

Amicalement,
--
Albert.
Loading...