Bug #7339
closed
Dyndns RFC2136 client, don't send updates via TCP.
Added by Eduardo Silva about 7 years ago.
Updated about 7 years ago.
Description
Hi, when i use dyndns rfc2136 client update, I check "Use TCP instead of UDP", the ouput command nsupdate add correctly the -v parameter, but nsupdate send updates via UDP (double checked).
-v parameter in nsupdate, must sent updates via TCP protocol.
System LOG:
rc.dyndns.update: The command '/usr/local/bin/nsupdate -k /var/etc/K0CLON.+157+00000.key -v /var/etc/nsupdatecmds0' returned exit code '1', the output was 'Communication with 179.27.xx.xx#53 failed: timed - out dns_request_createvia: not implemented'
Firewall LOG:
Mar 2 17:22:24 ► WAN 167.61.xxx.xx:29263 179.27.xx.xx:53 UDP
Is the parameter not implemented in nsupdate version of BSD ?
Tks in advance
- Status changed from New to Rejected
- Priority changed from High to Normal
- Affected Version deleted (
2.3.3)
- Affected Architecture added
- Affected Architecture deleted (
amd64)
That is an error from your DNS server, not the client.
TCP updates work well from here on 2.3.3.
Search for that error message and you'll find it is from BIND, not nsupdate.
Jim:
The packets in the filter log (pfsense 167.61.xxx.xx) shows port 53 UDP output packets insteads TCP.
I make float firewall rule for capturing an log this traffic.
Mar 2 17:22:24 -> WAN 167.61.xxx.xx:29263 179.27.xx.xx:53 UDP
In my tests DNS server (179.27.xx.xx), I have filtered UDP ports and only TCP port 53 packet are allowed.
Checking the firewall logs in DNS server, only have records from pfsense in UDP:53 not TCP:53.. I make double check about this.
The nsupdate is not allowing or implemented TCP update transport..... it is very strange...
Tks.
You have broken the update by blocking UDP. It performs the update via TCP, but it performs other parts of the action via UDP.
When I watch one update via TCP, first it queries the SOA via UDP and then the rest of the traffic is TCP.
-v
Use TCP even for small update requests. By default, nsupdate uses
UDP to send update requests to the name server unless they are too
large to fit in a UDP request in which case TCP will be used. TCP
may be preferable when a batch of update requests is made.
Again, just the update request portion is forced to TCP.
Which it does:
If it does not work for you, then your configuration (or expectations) are incorrect. There is no bug here. It is operating as expected, and it is using TCP when it should.
Tks Jim.. it is clear now...
Also available in: Atom
PDF
Updated by 
Updated by