Closed kdrenard closed 1 year ago
@kdrenard can you describe the packets you got that hit this? like what OPT record was before the EDNS0?
In a response from an an authoritative server, were there is (at least) one question, some set of answers and potentially additional records (e.g. glue) in the answer along with an additional record of type OPT that contains zero or more EDNS0 options in RDATA.
try: "dig @h.root-servers.net +nsid IN NS aaa." to generate a response packet
an and ns records are actually not a problem with the old code, unless they contain an OPT record themselves (is that possible?), but multiple OPTs in ar is.
Nice and easy combo EDNS0 size + nsid, will make creating PCAP for testing easy.
If I recall correctly, the AN and NS counts were never pulled from the DNS header (those lines were commented out), so there was no way to skip past them. It was just assumed that if an OPT was present, it would immediately follow the question(s), and it would be the first AR. Simple queries with only an OPT were just fine.
If I recall correctly, the AN and NS counts were never pulled from the DNS header (those lines were commented out), so there was no way to skip past them.
Ah yes, I read the diff in the PR wrong.
Why did you increase loop detection to 5 btw?
Why did you increase loop detection to 5 btw?
There were a few compressions that had at least 3 references (I believe they were in ARs for glue records) that were getting errors. The value 5 was a bit arbitrary, but I think at least 4.
Okay, I'm gonna fix all this in different PR's, break up the different "bugs". Will leave this open until all has been fixed.
Thanks @kdrenard !
Replaced by #293, #292, #294.
Account for answer and authority RRs in dns message before processing additional records. Also, account for multiple additional records when processing OPT RRs. Do not ignore answers and authority records when marshaling through DNS packet.