I don't think the first case would be fixed by using getDNSPacketLength(), since we would be inserting the new option after a record that is not the OPT one. None of these is correctly handled by addECSToExistingOPT() today. There are two separate cases, as far as I can tell, one where the OPT record is not the last one in the existing packet, and a second one where there is no other record after the OPT one but there is some trailing data. Thank you for reporting this, and for the initial analysis.
It can be decoded as an EDNS option into OPTION-CODE=8 ( edns-client-subnet), OPTION-LENGTH=7 octets, OPTION-DATA ECS: FAMILY=1 (IPv4), SOURCE PREFIX-LENGTH=24, SCOPE PREFIX-LENGTH=0, ADDRESS=127.0.0 (i.e., 127.0.0.0/24, which would be expected from the configured useClientSubnet=true)Ģ8259 octets missing from the invalid EDNS option More purported OPTION-DATA for the invalid EDNS option. It can be decoded as ASCII into "_test" (the rest of the configured trailing data). The purported beginning of OPTION-DATA for the invalid EDNS option. This is invalid as an EDNS option in this packet because its length is insufficient, but can be decoded as ASCII into "dans" (the beginning of the configured trailing data). (the DNS root, as required by RFC 6891)Īdditional-section RR CLASS=4096: OPT UDP payload size 4096 octetsĪdditional-section RR TTL=0: OPT EXTENDED-RCODE=0, VERSION=0, DO=0 (no DNSSEC)Īdditional-section RR RDLENGTH=23: OPT options length 23 octetsĮDNS option: OPTION-CODE=10 ( COOKIE), OPTION-LENGTH=8 octetsĮDNS option: OPTION-CODE=25697 ( Unassigned), OPTION-LENGTH=28275 octets. ĭNS message header QDCOUNT=1 (1 entry in the question section)ĭNS message header ANCOUNT=1 (0 RRs in the answer section)ĭNS message header NSCOUNT=1 (0 RRs in the authority section)ĭNS message header ARCOUNT=1 (1 RR in the additional section)Ġ3 77 77 77 06 67 6f 6f 67 6c 65 03 63 6f 6d 00Īdditional-section RR NAME=. Inspecting the above packet from the start of its DNS message header to show how useClientSubnet put its data in the wrong position, after inbound trailing data rather than inside the OPT RDATA: OctetsĭNS message header flags: QR=0 (query), OPCODE=0 (QUERY), RD=1 (recursion desired). And just like that issue, the correct fix should be use of getDNSPacketLength to determine the proper manipulation position. This issue is analogous to #6896, and is also a potential injection vulnerability. The result of increasing the OPT RDLENGTH but then inserting the option data at the wrong place like this is misinterpretation of data from the original inbound packet as EDNS option data, which is very likely invalid. Those indexes usually coincide, but they diverge when anything in the inbound message follows the OPT, such as a TSIG RR or trailing data. The two DNS servers are 216.146.35.35 and 216.146.36.36.This is indeed a bug with useClientSubnet, specifically that it is appending an EDNS option to the end of the packet rather than inserting it at the end of the existing OPT RR (see below). I highly recommend that if you use DynDNS, go check your servers now, make sure that you have 5.3.1, and uncheck that option ASAP!
On an Active Directory-joined server this will make the server unable to communicate with a domain controller and things like NPS will stop working immediately.
#Dyn updater keeps adding 216.146.35.35 update#
This update makes the option "Use Dyn Recursive DNS servers on this machine" default, and puts their two DNS servers in front of any other DNS servers you have configured on the server's NICs. This means you might have the client installed on domain-joined computers. I know a lot of people use this for Internet failover situations so if they fail over to a backup Internet connection inbound NATs will also fail over to the new Internet connection. Last night DynDNS rolled out version 5.3.1 of their DynDNS Updater tool that is installed on a computer and keeps a DNS name updated with the correct IP.