On Mon, Nov 14, 2022 at 11:15:13AM +0800, zhangjiangyu via Dnsmasq-discuss wrote: > On Sun, Nov 13, 2022 at 9:15:43PM +0800, Geert Stappers via Dnsmasq-discuss > wrote: > > > > > .... > > > > However I don't understand the problem. > > > > What I think what would help for getting more attention to the "problem", > > is having a `request0` and `response0` that is a valid / known good > > CERT query. > > Hi, > > The original valid response is like this: > |HEADER > |31 32 81 80 00 01 00 01 00 02 00 01 > | > |QUESTION > |06 63 65 72 74 30 31 07 65 78 61 6d 70 6c 65 00 00 25 00 01 > | > |ANSWER > |c0 0c 00 25 00 01 00 00 00 00 00 55 > | ff fe ff ff fe 33 11 5c 6f 2f 64 ff 2b de 74 c7 > | d0 80 ac e1 1f 97 ab d0 cb bf bc 82 f3 e3 92 24 > | b2 47 1e 14 68 22 58 29 ff 1b 11 e1 6a 2e 95 02 > | e1 c0 a0 d5 33 e1 8a 14 d6 d5 5f 48 24 aa 41 89 > | fa ff fd 75 53 a3 65 77 cd 23 11 e0 bc 69 3a ce > | f8 a2 a6 09 a6 > | > |AUTHORITY > |c0 13 00 02 00 01 00 00 00 00 00 06 > | 03 6e 73 34 c0 13 > | > |c0 13 00 02 00 01 00 00 00 00 00 06 > | 03 6e 73 32 c0 13 > | > |ADDITIONAL > |00 00 29 10 00 00 00 00 00 00 00 > Here is the download link for the valid message: > * request0 file: https://643684107.oss-cn-beijing.aliyuncs.com/dns/request0 > * response0 file: https://643684107.oss-cn-beijing.aliyuncs.com/dns/response0
Downloaded and added to public git repository https://git.sr.ht/~stappers/cert_check_by_dnsmasq ( Do `git clone https://git.sr.ht/~stappers/cert_check_by_dnsmasq` for getting a clone of it. ) > It can be found by comparison. What I noticed is that dnsmasq, version 2.87 as in Debian, did not return response0 when request0 was asked. The request-response-combos 1, 2 and 3 did work with the same dnsmasq. I shall retry with most recent dnsmasq. (Next action for this is for me.) > * For the first bug, The class value of answer record returned by > response1 is wrong, but it is accepted by dnsmasq and returned to > the client. Any modification of the answer record's class value is > acceptable. The rcode of the dnsmasq returned packet is 0. > * For the second bug, The domain name compression pointer of answer > record returned by response1 is wrong. The query domain name does > not match the answer domain name. The rcode of the dnsmasq returned > packet is 0. > * For the third bug, When the DNS packet returned by the domain name > server has redundant data, it is not detected. The rcode of the > dnsmasq returned packet is 0. That information will I add to the above mentioned git repository. > For these problems, other open source dns software has done correct > verification and returned to the client the message with rcode 2 or 3. Yes. Meanwhile I do understand what is being reported. It is the reason why I named the git repo "cert check by dnsmasq". > > With `host -p 5353 -t CERT cert01.example.com 127.0.0.1` > > or `dig @127.0.0.1 -p 5353 -t CERT cert01.example.com` being a replacement > > for the `python3 dns_request.py request0 5353`. > > For this, I use the python code to receive the message forwarded to > the client for analysis. Not sure if I did get that. Thing is that I now get why there is `dns_request.py` insteadof `dig` / `host`. Having build a 'requestA' plus 'responseA', doing `dig @127.0.0.1 -t A -p 53530 cert01.example.com` and seeing 'bad' in ; COOKIE: fc1cf816de5660db010000006371519ca741c7907b7a87c4 (bad) got me understand it. Groeten Geert Stappers P.S. After doing git clone https://git.sr.ht/~stappers/cert_check_by_dnsmasq cd cert_check_by_dnsmasq I recomment doing `git log --reverse` do read how it evolved. -- Silence is hard to parse _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
