Closed SUMUKHA-PK closed 3 years ago
We have to maintain two positions during jumps:
seek
method.pos
.When we encounter a jump instruction we extract the offset and adjust the pos
variable. This allows the reading of the qname to continue from that offset. When that has finished, though, and we want to issue the next read instruction, we want to continue from the point straight after the original jump instruction. That is two bytes further down the buffer, which is why we seek to there.
Hey, Sorry for the delayed response. I have been implementing a version of this myself in Golang and something seems to be off in Chapter 1. I was wondering if you could help me with it. Thanks.
https://github.com/SUMUKHA-PK/DNS-server/tree/master/Phase%202/src this is the link
and
"" I mentioned earlier that each label is preceeded by a single byte length. The additional thing we need to consider is that if the two Most Significant Bits of the length is set, we can instead expect the length byte to be followed by a second byte. These two bytes taken together, and removing the two MSB's, indicate the jump position. In the example above, we've got 0xC00C. The bit pattern of the the two high bits expressed as hex is 0xC000 (in binary 11000000 00000000), so we can find the jump position by xoring our two bytes with this mask to unset them: 0xC00C ^ 0xC000 = 12. Thus we should jump to byte 12 of the packet and read from there. Recalling that the length the DNS header happens to be 12 bytes, we realize that it's instructing us to start reading from where the question part of the packet begins, which makes sense since the question starts with the query domain which in this case is "google.com". ""
Shoudnt we jump by the number indicated after the set flag? Why are we jumping from
pos
topos+2
?