3 ms·

DNS has no version field. I'm torn as to the choice here. On the one hand, DNS is backwards compatible with everything. EDNS is the only way to extend the prot

DNS has no version field. I'm torn as to the choice here. On the one hand, DNS is backwards compatible with everything. EDNS is the only way to extend the protocol now, which is basically just adding additional Records to the Message that are designated as Extended DNS records, and treated specially.

oripring 8y ago
The message header hasn't been fully exhausted yet. Beyond the spare bit[1] in the header there is unassigned OPCODE values which can be used to bend the format in new ways[2]. 1] It was briefly used experimentally if I recall 2] https://tools.ietf.org/html/draft-ietf-dnsop-session-signal https://tools.ietf.org/html/draft-ietf-dnsop-session-signal
jburgess777 8y ago
The IETF is working on a document which describes many reasons why DNS may stop working. EDNS related issue are in section 3.2: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08 https://tools.ietf.org/html/draft-ietf-dnsop-no-response-iss...
- spc476 8y ago
  My own code to decode DNS packets [1] fell afoul of section 3.1.3 of the draft document. I fixed the issue, but the reason I originally rejected DNS packets with unknown flags was on the assumption of potential garbage being used as a possible exploit. [1] https://github.com/spc476/SPCDNS https://github.com/spc476/SPCDNS
- bluejekyll 8y ago
  This is a great resource. Thank you for sharing. I don’t read that as DNS stoping to work, but more reasons why DNS is flaky in different scenarios. Some of the issues there are things related to mitigation’s against reflection attacks etc. I haven’t read the entire doc, but does it go into concerns around DDOS and other such things, and how DNS servers to mitigate those attacks? Edit: right in the intro. So a server needs to “understand” when it is under “attack” and only then put in mitigations against the attack. In the worst case, the server doesn’t do this, fixes the issues in this RFC to always respond and then amplify the attack.

oripring 8y ago

The message header hasn't been fully exhausted yet. Beyond the spare bit[1] in the header there is unassigned OPCODE values which can be used to bend the format in new ways[2]. 1] It was briefly used experimentally if I recall 2] https://tools.ietf.org/html/draft-ietf-dnsop-session-signal https://tools.ietf.org/html/draft-ietf-dnsop-session-signal

jburgess777 8y ago

The IETF is working on a document which describes many reasons why DNS may stop working. EDNS related issue are in section 3.2: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-08 https://tools.ietf.org/html/draft-ietf-dnsop-no-response-iss...

spc476 8y ago
My own code to decode DNS packets [1] fell afoul of section 3.1.3 of the draft document. I fixed the issue, but the reason I originally rejected DNS packets with unknown flags was on the assumption of potential garbage being used as a possible exploit. [1] https://github.com/spc476/SPCDNS https://github.com/spc476/SPCDNS
bluejekyll 8y ago
This is a great resource. Thank you for sharing. I don’t read that as DNS stoping to work, but more reasons why DNS is flaky in different scenarios. Some of the issues there are things related to mitigation’s against reflection attacks etc. I haven’t read the entire doc, but does it go into concerns around DDOS and other such things, and how DNS servers to mitigate those attacks? Edit: right in the intro. So a server needs to “understand” when it is under “attack” and only then put in mitigations against the attack. In the worst case, the server doesn’t do this, fixes the issues in this RFC to always respond and then amplify the attack.