Closed jerith closed 3 years ago
I'm currently working on this issue and I've run across an interesting issue with dig
on OS X where it is not sending the qr
bit. Example:
$ dig example.com +qr
; <<>> DiG 9.12.1 <<>> example.com +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55102
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 43f1a9606bbeb588
;; QUESTION SECTION:
;example.com. IN A
;; QUERY SIZE: 52
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55102
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 1030 IN A 93.184.216.34
;; Query time: 111 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Apr 26 06:55:40 PDT 2018
;; MSG SIZE rcvd: 56
I am researching why this is the case, and determining if there is a more comprehensive means for determining if a question is really a question.
And I'm silly... of course the qr
bit is 0 when it's a query:
QR - A one bit field that specifies whether this message is aquery (0), or a response (1).
Taking myself off of this for now. I will try to get back to it at some point.
I was looking into this again, and I wonder if it is still possible today for this to create a denial of service condition? The reason I ask is because erldns_worker:handle_decoded_udp_message
will not process a message where the qr
bit is set to 1, rather it will return {error, not_a_question}
which should result in the packet being dropped. Can you reproduce this with the current version of erldns?
I'm closing this for now. Feel free to reopen if it is still an issue.
It is possible, in some circumstances, for erl-dns to receive a UDP query from the address and port it's listening on. (See https://jira.mesosphere.com/browse/DCOS_OSS-2109 for debugging and discussion.) When this happens, erl-dns treats its own reply as an incoming message and responds to it in an infinite loop. Even if the conditions for an accidental loop are not met, this is still a potential denial of service vector.
I believe an appropriate solution would be to ignore any messages that appear to originate from the listening socket.