Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change to default unbound #1539

Open
bwbroersma opened this issue Nov 7, 2024 · 2 comments
Open

Change to default unbound #1539

bwbroersma opened this issue Nov 7, 2024 · 2 comments
Milestone

Comments

@bwbroersma
Copy link
Collaborator

It seems a default unbound could be used, processing the stdout (or maybe different stream) to redis-cli (via some sed or awk).

Sample unbound.conf:

server:
  num-threads: 2
  username: "unbound"
  local-zone: "." refuse
  local-zone: "test.example" transparent
  interface: 0.0.0.0

  access-control: 0.0.0.0/0 refuse_non_local

  module-config: "iterator"
  chroot: ""

  logfile: /dev/stdout
  verbosity: 1
  log-queries: yes

auth-zone:
  name: "test.example."
  zonefile: "/etc/unbound/test.zone"
  fallback-enabled: no
  for-upstream: no
  for-downstream: yes

Sample test.zone:

		SOA ns.test.example. example.test.example (
			4 ; serial - do not remove this command, used for resigning!
			14400
			3600
			604800
			3600
)
		NS ns
ns		A	1.0.0.0

*	A	2.0.0.0

Running this:

$ docker run -it --rm -v unbound.conf:/etc/unbound/unbound.conf -v test.zone:/etc/unbound/test.zone alpinelinux/unbound "unbound -d"

Query it (in my case the IP was 172.17.0.4, yours will likely differ):

$ dig +norec a.test.example @172.17.0.4

; <<>> DiG 9.16.50-Debian <<>> +norec a.test.example @172.17.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34178
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;a.test.example.			IN	A

;; ANSWER SECTION:
a.test.example.		3600	IN	A	2.0.0.0

;; Query time: 0 msec
;; SERVER: 172.17.0.4#53(172.17.0.4)
;; WHEN: Thu Nov 07 00:53:55 CET 2024
;; MSG SIZE  rcvd: 59
$ dig a.test.example @172.17.0.4      

; <<>> DiG 9.16.50-Debian <<>> a.test.example @172.17.0.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20803
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;a.test.example.			IN	A

;; ANSWER SECTION:
a.test.example.		3600	IN	A	2.0.0.0

;; Query time: 0 msec
;; SERVER: 172.17.0.4#53(172.17.0.4)
;; WHEN: Thu Nov 07 00:54:06 CET 2024
;; MSG SIZE  rcvd: 59

The log contains:

[1730937235] unbound[1:0] info: 172.17.0.1 a.test.example. A IN
[1730937246] unbound[1:0] info: 172.17.0.1 a.test.example. A IN

Note this configuration differs from the current one used in:

  • refuse_non_local
  • for-upstream: no
  • for-downstream: yes
@bwbroersma bwbroersma added this to the intake milestone Nov 7, 2024
@mxsasha
Copy link
Collaborator

mxsasha commented Nov 7, 2024

This thought did occur to me - another alternate is that we could consider whether all of this is worth it, given that the only custom feature that is live right now, is to display the name of the user's resolver in the conntest.

However, our custom unbound module also has code to dynamically generate records for an inbound mail test. I don't know what the background or state of that is, and I haven't thought through where the dynamic part is needed. But it's why we haven't switched it out yet.

Vaguely related: #1378 to stop linking unbound into our Python code and just talk to either resolver over UDP. There is no need for this anymore.

@bwbroersma
Copy link
Collaborator Author

Thanks for the linking. I am aware of the interactive mail test (that currently is not used), should also look into that before migrating away. It would really be nice to drop the patched unbound (while still keeping unbound), especially if no functionality is lost. I would prefer keep listing the resolver IP / AS name, since sometimes (e.g. #1421) this is not what a user might think, and debugging it without the resolver IP / AS name could be very hard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants