Hot answers tagged

80

To test if udp port is responding, use netcat. An example from the man page: nc -v -u -z -w 3 example.host 20-30 Send UDP packets to ports 20-30 of example.host, and report which ones did not respond with an ICMP packet after three seconds. Of course, if a firewall is DROPing, which is normally the case when dealing with internet-faced gateways, ...


57

both on client ans server install nc: yum install nc (for centos) on server listen UDP port: nc -ul 6111 on client nc -u <server> 6111 type anything on client and hit enter - you should see this text on server Note: When you run the nc -ul command on the server, it will only connect for the first connection coming to it. You can't, as I found out, ...


43

stream needs to be on the same level as http block so like http { foo } stream { bar } My guess is your include for /etc/nginx/conf.d/*.conf is located in the http {} block and not outside of it. Checkout the /etc/nginx/nginx.conf for the include and maybe you have to make a new one for the stream section


40

The logic works like this: Only authoritative DNS servers that provide records to the internet are required to be exposed. Open recursive servers that are exposed to the internet will inevitably be found by network scans and abused. (See user1700494's answer) The likelihood of someone accidentally standing up an exposed recursive server is greater than that ...


40

Normal DNS queries use UDP port 53, but longer queries (> 512 octets) will receive a 'truncated' reply, that results in a TCP 53 conversation to facilitate sending/receiving the entire query. Also, the DNS server binds to port 53, but the query itself originates on a random high-numbered port (49152 or above) sent to port 53. The response will be returned ...


33

can TCP packets arrive to receiver by pieces? Yes. IP supports fragmentation, though TCP generally tries to determine the path MTU and keep its packets smaller than that for performance reasons. Fragmentation increases the datagram loss rate catastrophically. If a path has a 10% packet loss rate, fragmenting a datagram into two packets makes the datagram ...


29

This started as a comment to George's answer, but it got long. The larger picture is somewhat complicated, as it requires understanding some history. RFC 1035 originally called for a limit of 512 bytes in order to avoid UDP fragmentation. Fragmented UDP datagrams and TCP were chosen as the options of last resort in order to minimize the overhead of DNS ...


24

For example, attackers could use university's DNS server as transit host for DNS Amplification DDoS Attack


22

I had exactly the same problem and unfortunately auditd didn't do much for me. I had traffic from some of my servers going towards google DNS addresses, 8.8.8.8 and 8.8.4.4. Now, my network admin has mild OCD and he wanted to clean all the unnecessary traffic since we have our intern DNS caches. He wanted to disable outgoing port 53 for everyone except ...


20

You can't be sure that they really physically arrive at once. The Data link layers below TCP/UDP might split your packet up if they want to. Especially if you send data over the internet or any networks outside of your control it's hard to predict that. But no matter if the data arrives in one packet or multiple packets at the receiver. The OS should ...


18

Examples. Blocks of contiguous characters correspond to send() calls: TCP: Send: AA BBBB CCC DDDDDD E Recv: A ABB B BCC CDDD DDDE All data sent is received in order, but not necessarily in the same chunks. UDP: Send: AA BBBB CCC DDDDDD E Recv: CCC AA E Data is not necessarily in the same order, and not necessarily received at all, but ...


15

UDP datagrams have little to do with the MTU size you can make them as big as you like up to the 64K is maximum mentioned above. You can even send one of them in an entire packet as long as you are using jumbo frames with a size larger the large datagram. However jumbo frames have to be supported by all the equipment the frame will pass over and this a ...


15

Don't load balance your DNS. It's an incredibly light protocol - you'd need an enormous amount of traffic to need more than one box (in which case you'll just be bottlenecking on your load balancer anyway), and there's resilience built in because you can use multiple NS records in your delegation (other servers will be used if one's down).


14

RSS too is enabled in the NIC settings, with 8 queues. Which unfortunately did not mean that RSS was being employed, as netsh int tcp show global showed: TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : disabled After running (btw without rebooting) netsh int tcp set global rss=enabled RSS started ...


12

You do not "add" a broadcast address. You direct traffic to the broadcast address of a network. The broadcast address is an entirely virtual concept, and should not be "added" or otherwise assigned to any host in normal practice. The exception to the above rule is specifying the broadcast address (using ifconfig broadcast) which is done in cases where the ...


12

ARP Connection oriented or connectionless? Connectionless - it's just a request and a response (or a broadcast just letting everyone know about something). It uses TCP It doesn't use TCP - TCP is a layer 4 protocol, whereas ARP is glue between layers 2 and 3.


11

I'm uncomfortable with this Q&A because it hasn't really been established what type of DNS server you're talking about. There are some significant misconceptions when it comes to the resiliency of recursive DNS and it's important that people cruising in via search engines don't walk away from this discussion with a false sense of security. Authoritative ...


11

Both UDP and TCP does not include source address Your question is based on a misunderstanding. It's true that neither UDP or TCP headers include a source address, but that's because they don't have to: source address is already included in the header of the encapsulating transport protocol, which in this case would be the IP header. As for why UDP spoofing ...


11

Andrew B's answer is excellent. What he said. To answer the question "What undesirable things could happen if incoming UDP packets to port number 53 weren't blocked?" more specifically, I googled "DNS-based attacks" and got this handy article. To paraphrase: Distributed Reflection DoS attack Cache poisoning TCP SYN floods DNS tunneling DNS hijacking ...


11

DNS, by default and when created, does not offer neither authenticity (being sure you get a response from the true authoritative nameserver of the zone) nor confidentiality (making sure no one on the wire can understand your query or your answers). DNSSEC was created to solve the authenticity problem, because it allows one to sign records, and through a ...


10

You can use netcat. In OSX, this is my command: $ nc -vnzu <IP> <PORT> found 0 associations found 1 connections: 1: flags=82<CONNECTED,PREFERRED> outif (null) src <SOURCE IP> port <SOURCE PORT> dst <DEST IP> port <DEST PORT> rank info not available


10

When tcpdump is running, it will be fairly prompt at reading in the incoming frames. My hypothesis is that the NIC's packet ring buffer settings may be a bit on the small size; when tcpdump is running it is getting emptied in a more timely manner. If you're a Red Hat subscriber, then this support article is very useful Overview of Packet Reception. It has ...


9

Nowadays HTTPS can run above either TCP or UDP. The new "QUIC" protocol aims to replace multiple TCP connections with one multiplexed UDP connection, and hence can handle SSL and HTTPS: HTTPS → SSL → QUIC flow → UDP → IP QUIC was originally developped in 2012 by Google and is undergoing IETF review. For more details, see Wikipedia.


9

For some reason, Andrew's solution didn't work for me. With further research, I learned that we need to add -p flag when working locally. So the following command worked for me. nc -ulp 2115


9

As it is said above, iperf limits itself by design. In src/Client.cpp, method void Client::Run( void ) calls ReportPacket( mSettings->reporthdr, reportstruct ); after writing each UDP datagram. ReportPacket() is rather slow and it slows the whole thing. In iperf3, burst writes are introduced for UDP, you can specify number of burst writes in -b ...


8

I know this question is almost two years old, but it has no answers, so I thought I'd chime in with a way to handle this. This is actually something that works with UDP only because it is stateless, and will not work with TCP. Your described setup with a TCP connection to a third "control" server is actually the perfect setup for this. We'll call the ...


8

There is no problem. This is normal and expected behaviour. The reason for the packet loss is that UDP doesn't have any congestion control. In tcp when congestion control algorithms kick in, it will tell the transmit end to slow down the sending in order to maximise throughput and minimise loss. So this is entirely normal behaviour for UDP actually. UDP ...


8

Depending on how nice you want to be to the client, a possible solution can be: iptables -I INPUT -p udp --dport 111 -j DROP or iptables -I INPUT -p udp --dport 111 -j REJECT


8

You can easily accomplish this with SysInternals' Process Monitor. Run it as Administrator, then configure it as follows: On the Filter menu click Filter... In the first drop down box, select Operation. Select Is for the match condition, then in the blank drop-down box select UDP Send, then click Add. Again, in the first drop-down box, select Path. Select ...


Only top voted, non community-wiki answers of a minimum length are eligible