Does regexp on response-blocklist-name works on any record type?

[cbuijs]

Should response-blocklist-name when using regexp hit anything in the answer, regarrdless record-type? Like HTTPS and SVCB records as well?

For example, I want to block an HTTPS record like below:
blah.company.com. 120 IN HTTPS 1 . ipv4hint=\"1.2.3.4\" ipv6hint=\"1234:1:2:3::4\"

By using an regexp like this (stupid/simple example):
^ipv4hint

It seems to work on CNAME and the more traditional records only?

[folbricht]

It supports a subset of record types. You can see the list here https://github.com/folbricht/routedns/blob/master/response-blocklist-name.go#L77-L86

Should be easy to add something if necessary.

[cbuijs]

Ah! Wait. I think we discussed this before :-).

I think it is probably okay and not a lot of work to at least the following record-types as well, where the last field in the answer is "text" and to be considered parseable (the other fields require more work I guess, but less relevant anyway):

TXT
HTTPS
SVCB

Not sure if the DNS Lib provide those fields as "text" as the HTTPS and SVCB normally seems to be encoded in some format. The HTTPS and SVCB ones are quite new, but the HTTPS is in use A LOT already.

[folbricht]

Can you try out the issue-341 branch? For the TXT records, I had to join the values with a , since there can be multiple strings in that. Not sure if I should use a newline or something else there

[cbuijs]

COOL!

I had this issue with TXT before, and concatenate them with a space (and unduplicate any double-spaces that could be a result), which seems to be a common way of doing it.

Will try/test later (probably tomorrow, swamped today).

[folbricht]

Just updated it to join with whitespace

[cbuijs]

Seems not to work. I didn't spend too much time on it. Looks like the regexp format I am using, isn't used somehow.

example:

[groups.blocklist-response-name]
type = "response-blocklist-name"
resolvers = ["google-doh"]
blocklist-format = "regexp"
blocklist= [
    '^.*ipv[46]hint.*$',
]

Result should be that all HTTPS records containing either ipv4hint or ipv6hint should be blocked. But isn't.

[cbuijs]

I think (wild guess) is that r.Target for HTTPS record type, according spec, is encoded in Base64 (decoding it would turn it into text), but I am not sure. Not sure if the Mieks lib decodes it already or not.

Same for SVCB.

[folbricht]

The issue is that "Target" is just the target string, i.e. just . in your example. The values are encoded separately. I pushed a change to encode the values like . ipv4hint=1.2.3.4 ipv6hint=1234:1:2:3::4 without the quotes. So your regexp should work now.
Not sure if this is the right thing to do though, since it's no longer blocking based on "Target" only, but let's see how this works out first

[cbuijs]

Not working still (using same example config above):

kdig one.one.one.one https
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 43692
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; one.one.one.one.    		IN	HTTPS

;; ANSWER SECTION:
one.one.one.one.    	300	IN	HTTPS	1 . alpn=h3,h2 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001

;; Received 121 B
;; Time 2023-10-23 11:51:52 CEST
;; From 192.168.1.32@53(UDP) in 27.2 ms
chris-eip-air:~ chrisbuijs$ kdig one.one.one.one https
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 21459
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; one.one.one.one.    		IN	HTTPS

;; ANSWER SECTION:
one.one.one.one.    	287	IN	HTTPS	1 . alpn=h3,h2 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001

[folbricht]

Did you update from the branch before testing? I just tried it again and it seems to be working.

Logs

TRAC[0054] opening connection                            addr="1.1.1.1:853"
TRAC[0054] sending query                                 addr="1.1.1.1:853" qname=one.one.one.one.
DEBU[0054] blocking response                             client=127.0.0.1 id=cloudflare-blocklist qname=one.one.one.one. qtype=HTTPS rule="^.*ipv[46]hint.*$"
TRAC[0064] connection terminated by idle timeout         addr="1.1.1.1:853"

Config

[groups.cloudflare-blocklist]
type             = "response-blocklist-name"
resolvers        = ["cloudflare-dot"]
blocklist-format = "regexp"
blocklist= [
    '^.*ipv[46]hint.*$',
]

Output

$ dig -p 1153 @127.0.0.1 HTTPS one.one.one.one

; <<>> DiG 9.18.19 <<>> -p 1153 @127.0.0.1 HTTPS one.one.one.one
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19249
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;one.one.one.one.		IN	HTTPS

;; Query time: 112 msec
;; SERVER: 127.0.0.1#1153(127.0.0.1) (UDP)
;; WHEN: Sat Oct 28 08:40:57 CEST 2023
;; MSG SIZE  rcvd: 33

[cbuijs]

Cool. Will do a rebuild and test again in the next couple of days and let you know.

[cbuijs]

Something I will be creating another ticket for but that just popped in my mind reading this all.

Would be cool that we can somehow use the existing block features by defining a regex where to match against.

For example response-ip not only looking in A or/and AAAA records, but in parts of targets of other records too.

For example if we take the above example, and we want to match 1.1.1.1 as address, a matching/capturing regex could be given like this:

^.*ipv[46]hint=(?P<IP>[^\s]+).*$

The parentheses bit will be captured into IP that would be used to match against the list (using IP-Address here as example). I think ?P is not existent in GO regex, but just to make the point.

Hope this is clear.

[cbuijs]

Just tested after rebuild and it works:
msg="blocklist match, forwarding to blocklist-resolver" client=192.168.1.122 id=test qname=one.one.one.one. qtype=HTTPS resolver=noerror rule="^.*ipv[46]hint.*$"

[folbricht]

Thanks for checking it out. Merged