[Dnsmasq-discuss] dnsmasq mishandles some cases when bad dns response packet is received

[Geert Stappers]

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