Re: [Dnsmasq-discuss] Picking up the patches
Le ven. 17 mars 2023 à 06:03, Petr Menšík a écrit : > > Could we perhaps make some service, which would gather list of patches > sent to mailing list. Sounds like patchwork (not really a user, I just know OpenWrt uses it) If you don't want to host it or just want to try it out, ask to be added to ozlabs.org one https://patchwork.ozlabs.org/about/ > And if Simon would not respond to it in any way, > it would make a list of sender, subject and name of patches in a summary. > > If no response were say in a week, it might send a summary mail with a > list of such pending patches. Maybe supporting some keywords to mark a > reason, why it is not merged (yet). > > It might be doable > > Examples: > > [merged] - merged as it is. In some cases this could be detected without > any message by watching git repo. > > [modified] - merged by a different change. Solved the problem in a > different way. > > [modify] - request to make a changes in patch, is waiting on the > contributor to do so > > [refused] - stating such change won't be merged even with small > modifications, stop tracking that patch. > > Altough it would be much easier if Simon would accept also pull requests > on any kind of git hosting service, which already provides a way to > create pull request, which can be commented on, merged or closed. > Services like github.com, gitlab or pagure already implements similar > workflows. > > But above proposal would allow Simon just add those keywords into his > reply and otherwise do not change his way of processing incoming > patches. It would require to do some coding by us and hosting such > service somewhere. > > Maybe even very simple reminder threads containing patches do not > contain any message for some time from Simon would help. Looking at > pipermail threads page, some hacking at HTML level in python might solve > that. Ideally with once a day generated page of links to messages > waiting for any comment, which could be checked any time. > > On 3/16/23 22:51, Geert Stappers wrote: > > Hi, > > > > How can I help that patches get the attention that they deserve? > > > > > > Groeten > > Geert Stappers > > > > > > On Wed, Mar 08, 2023 at 03:38:02PM +, Simon Kelley wrote: > >> On 07/03/2023 23:20, Clayton Craft wrote: > >>> On Thu, 23 Feb 2023 21:40:10 -0800 Clayton Craft wrote: > On Fri, 10 Feb 2023 13:53:05 -0800 Clayton Craft wrote: > > Any chance this could get merged? Being able to set filters at runtime > is very > useful for multi-homed phones and other devices in cases where we need to > restrict DNS response answers based on IP protocol. > > Please let me know if I need to make changes so that it is acceptable. > >>> Is this patch something that could be accepted? > >>> > >> Apologies for ignoring you. Patch looks fine. Applied to git repo. > >> > >> > >> Cheers, > >> Simon. > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Report filtered A or AAAA records via EDE code
I think that looks like a sensible change. I'm slightly worried about the definition of EDE_FILTERED 4.18. Extended DNS Error Code 17 - Filtered The server is unable to respond to the request because the domain is on a blocklist as requested by the client. Functionally, this amounts to "you requested that we filter domains like this one." Which talks about domains and not RRtypes. You can imagine a client noting that a domain is filtered and not sending other queries for the domain, when in this case they are fine, it's the RRtype which is being filtered. Simon. On 16/03/2023 20:58, Petr Menšík wrote: Hi! I have raised filtering topic on DNS-OARC chat. One of proposals were to mark at least filtered records by EDE status, which current dnsmasq supports already. I like it. We create fake answer on when --filter-A or --filter- options is used. It should be marked somehow. There is also proposal for more verbose error and contact information [1], but at least marking the response somehow synthetized is a good start. I attached a change to rrfilter to report number of modified records. Then it marks any filtered response with Filtered EDE code. I expect the same should be possible for any other record type filtered, except EDNS0 and DNSSEC records. Credits for the idea goes to Vladimír Čunát. It might allow potential DNSSEC validator to not emit SERVFAIL on bogus answer we made. If that would trust our response for any reason. What do you think? By the way, maybe we should strip also RRSIG for those records if present. It looks like a bug to me. But would not make validating resolvers more happy anyway. ; <<>> DiG 9.18.12 <<>> -4 @localhost -p 2053 example.org a +dnssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21029 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1220 ; COOKIE: b2ad85a9275d948e02176a79641381dce6990a257f089ec5 (good) ; EDE: 17 (Filtered) ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org. 32748 IN RRSIG A 8 2 86400 20230323193411 20230302075235 43798 example.org. QwrK73kR5vStRzG6IPOpYU2exzSIOatl1p8DffKi4PP2Ig8yAL43AhVu 2bsA0I0EFINH3xvF2IiM7eyR/fMm8rfeAsG1pokOFOOhlYQQHhglgfu6 mgNJnFrHUs3M+JNBNyAay42aSSDt5gXcvk77nx32uWv40pfknU7wH2Xc rP4= [1] https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] State of blocking type=65 requests?
On 16/03/2023 16:04, Petr Menšík wrote: I do not like attempts to filter out valid queries from clients on the side of dns cache. It should cache the HTTPS type, which it currently does not. That makes those kind of queries much more expensive. Agree about HTTPS caching. I think it should be fixed on the side of clients instead. If they ask for all addresses, just give them when they do exist. If the network is very expensive (can you be more concrete about type of connection?) then find a way to tell clients what it does provide (and what it does not). It does not provide IPv6? Well, then clients should not ask for it without a reason. They also have to be special on such expensive network, haven't they? I expect they have to be tuned somehow to avoid unnecessary network communication anyway. Ed can answer this. What is a good response for record, which may exist, but we pretend it does not? NODATA or REFUSED? NODATA or NXDOMAIN are the only good answers. You can answer NXDOMAIN if a query for another RRtype for the same domain returned NXDOMAIN. You can also answer NODATA if that query returned an answer or NODATA. If you don't have the answer to another query, then you have to send it upstream. The current dnsmasq code handles cached NXDOMAIN. This is valid, not just if you're filtering the requested rrtype. I'm tempted to add the NODATA check, that's only useful with filtering. All similar quirks break DNSSEC deployment. Having DNS clients of dnsmasq which do DNSSEC validation is pretty hopeless anyway. It will work only if you don't use any the facilities in dnsmasq to alter the client's view of the DNS. No overriding A/ records in /etc/hosts or --address. No generating A, or other record types in dnsmasq. The only way it works is just using dnsmasq as a pure caching forwarder. That's a valid use case, but lots of people use dnsmasq to alter the client's view of the DNS and that's a valid use case too and there's no reason to avoid additional features that do it. Would you want also EDNS0 extension stripped from forwarded queries? Or at least reset DO bit to 0 always? I would prefer if it could return REFUSED to queries it does not want to forward. Faking empty responses is poor man's choice just to dodge assumptions on multiple sides. But if it does not want to forward something , I think REFUSED would be correct response. It would also solve problem to decide whether to send NOERROR or NXDOMAIN. And would cause no forwarded queries of unwanted types. The problem with REFUSED is that the behaviour of resolvers to a REFUSED answer is not well defined. I bet lots of them will just retry, especially when they only have one recursive server configured. That's not very useful. If it would work the same way as faking empty responses, I would vote for --reject-rrset=https instead of --filter-rrset=https. would be probably more difficult, because getaddrinfo(AF_UNSPEC) implementations may not handle REFUSED just one one of two queries well. But if browsers doing HTTPS would handle it better, please try that first. I admit I haven't tried. But HTTPS should not have similar legacy problems, it may work better. I think we have consensus that that filter-a and filter- should be generalised to filer=rrset. I'd also like to generalise the cache to allow something like cache-rrtype=SRV or cache-rrtype=https. Simon. Regards, Petr On 06. 03. 23 23:36, Ed W wrote: Hi, can I get a leg up in understanding the options for blocking dns queries for a specific resource type, specifically type 65 queries I see there was a patch to implement a "filter-http" option here: https://github.com/rozahp/dnsmasq It possibly seems like there is a filter- implemented in dnsmasq already, so I wonder if there is appetite for the filter-http to also be accepted? My motivation for needing this is that we operate a firewalling system for a very bandwidth constrained system (even DNS is extremely expensive) and we operate a 'blocked unless whitelisted' firewalling system. The type 65 queries are currently inhibiting some of the whitelisting capability. Whilst we can potentially improve things, the short term solution would be to block type 65 I see that there is an option in pi-hole, but I'm looking for an option within dnsmasq, ideally without maintaining my own out of tree patch Have I missed a solution that is possible within vanilla dnsmasq? Has the idea to implement a filter-http option been rejected already? (I'm happy to send a patch if not?) Thanks Ed W ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cg
Re: [Dnsmasq-discuss] Picking up the patches
Could we perhaps make some service, which would gather list of patches sent to mailing list. And if Simon would not respond to it in any way, it would make a list of sender, subject and name of patches in a summary. If no response were say in a week, it might send a summary mail with a list of such pending patches. Maybe supporting some keywords to mark a reason, why it is not merged (yet). It might be doable Examples: [merged] - merged as it is. In some cases this could be detected without any message by watching git repo. [modified] - merged by a different change. Solved the problem in a different way. [modify] - request to make a changes in patch, is waiting on the contributor to do so [refused] - stating such change won't be merged even with small modifications, stop tracking that patch. Altough it would be much easier if Simon would accept also pull requests on any kind of git hosting service, which already provides a way to create pull request, which can be commented on, merged or closed. Services like github.com, gitlab or pagure already implements similar workflows. But above proposal would allow Simon just add those keywords into his reply and otherwise do not change his way of processing incoming patches. It would require to do some coding by us and hosting such service somewhere. Maybe even very simple reminder threads containing patches do not contain any message for some time from Simon would help. Looking at pipermail threads page, some hacking at HTML level in python might solve that. Ideally with once a day generated page of links to messages waiting for any comment, which could be checked any time. On 3/16/23 22:51, Geert Stappers wrote: Hi, How can I help that patches get the attention that they deserve? Groeten Geert Stappers On Wed, Mar 08, 2023 at 03:38:02PM +, Simon Kelley wrote: On 07/03/2023 23:20, Clayton Craft wrote: On Thu, 23 Feb 2023 21:40:10 -0800 Clayton Craft wrote: On Fri, 10 Feb 2023 13:53:05 -0800 Clayton Craft wrote: Any chance this could get merged? Being able to set filters at runtime is very useful for multi-homed phones and other devices in cases where we need to restrict DNS response answers based on IP protocol. Please let me know if I need to make changes so that it is acceptable. Is this patch something that could be accepted? Apologies for ignoring you. Patch looks fine. Applied to git repo. Cheers, Simon. -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
