fix: RFC correctness driven updates#124
Merged
Merged
Conversation
- fix(packet): Name decode rejects pointer cycles (RFC 1035) - fix(packet): EDNS exposes extendedRcode/version/doFlag; udpPayloadSize configurable (RFC 6891) - fix(packet): Header initializes ancount; AD/CD bits split from Z (RFC 4035) - fix(packet): ECS encoder truncates address to ceil(prefix/8) octets, adds IPv6 family (RFC 7871)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📑 Description
✅ Checks
Extra info
RFC 1035 §4.1.4
Packet.Name.decode(packet.js:443–465) follows compression pointers by jumpingreader.offsetdirectly. A crafted packet whose pointer chain forms a cycle (pointer → pointer → original) causes unbounded recursion /infinite loop, which can crash the process or consume 100% CPU.
RFC 6891 §6.1.3, RFC 4035 §3.2.1
The EDNS OPT record TTL field encodes (in order): 8 bits extended RCODE, 8 bits EDNS version, 1 bit DO (DNSSEC OK), 15 bits reserved Z. dns2 always hardcodes
ttl: 0on both encode and decode (packet.js:735,packet.js:743), meaning:RFC 1035 §4.1.1 (header field layout)
Packet.Header(packet.js:231–248) initialisesqdcount,nscount, andarcountto0, butancountis absent. A freshly constructedPacket.Headertherefore hasheader.ancount === undefined.toBufferworks around this by re-assigning
this.header.ancount = this.answers.length, but any code that inspectsheader.ancountbefore callingtoBufferwill readundefinedrather than0.RFC 7871 §6 (EDNS Client Subnet option encoding)
Packet.Resource.EDNS.ECS.encode(packet.js:835–844) always writes all four IPv4 address octets regardless ofsourcePrefixLength. RFC 7871 §6 says the ADDRESS field must contain only the significant octets:⌈sourcePrefixLength/ 8⌉ bytes. Sending extra octets is a spec violation and wastes space.Additionally the encoder splits
record.ipon.(IPv4 only); an IPv6 CIDR (family 2) will produceNaNbytes for each octet.RFC 4035 §3.2.3
RFC 4035 repurposed the two formerly-zero Z bits in the DNS header as AD (Authentic Data, bit 5) and CD (Checking Disabled, bit 6). dns2 reads all three Z bits as a single
zvalue and provides no separateadorcdaccessors. Clients cannot set or check these flags independently, making DNSSEC validation signalling impossible.