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

Feature request:" Return SOA record in AUTHORITY SECTION when sending dnsdist generated NXDOMAIN #4747

Closed
arjenz opened this issue Dec 6, 2016 · 14 comments · Fixed by #8171

Comments

@arjenz
Copy link
Contributor

arjenz commented Dec 6, 2016

  • Program: dnsdist
  • Issue type: Feature request

Short description

When generating a NXDOMAIN response (with RCodeAction(3)) with dnsdist, it might be nice to also supply a SOA record in the AUTHORITY section of the response.

Steps to reproduce

  1. dnsdist -l 127.0.0.1:5354 -a 127.0.0.0/8
  2. > addAction(RegexRule(".dnsdist.org"), RCodeAction(3))
  3. % dig nxdomain.dnsdist.org @127.0.0.1 -p 5354

Expected behaviour

Getting a response with AUTHORITY: 1 and a SOA record in the AUTHORITY section.

Actual behaviour

% dig nxdomain.dnsdist.org  @127.0.0.1 -p 5354

; <<>> DiG 9.8.3-P1 <<>> nxdomain.dnsdist.org @127.0.0.1 -p 5354
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48093
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nxdomain.dnsdist.org.		IN	A

;; AUTHORITY SECTION:
dnsdist.org.		3600	IN	SOA	pdns-public-ns1.powerdns.com. pieter\.lexis.powerdns.com. 2016020401 10800 3600 604800 10800

;; Query time: 273 msec
;; SERVER: 127.0.0.1#5354(127.0.0.1)
;; WHEN: Tue Dec  6 13:51:46 2016
;; MSG SIZE  rcvd: 115
  1. > addAction(RegexRule(".dnsdist.org"), RCodeAction(3))
% dig nxdomain.dnsdist.org  @127.0.0.1 -p 5354

; <<>> DiG 9.8.3-P1 <<>> nxdomain.dnsdist.org @127.0.0.1 -p 5354
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37895
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;nxdomain.dnsdist.org.		IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5354(127.0.0.1)
;; WHEN: Tue Dec  6 13:53:22 2016
;; MSG SIZE  rcvd: 38

Other information

Usecase

Getting a response that's more like a "real" authoritative nameserver.

Description

Fill the AUTHORITY section on generated NXDOMAIN responses.

@M4t7e
Copy link

M4t7e commented Feb 13, 2018

I can see the same behaviour with an empty response without errors. For example with RCodeAction(dnsdist.NOERROR) the AUTHORITY section is not set:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40516
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

It would be great to get there a SOA record in the response as well 😃

@johnhtodd
Copy link

johnhtodd commented Jun 11, 2019

I'm not sure that setting AUTHORITY is the right thing to do here on these responses. If these are internally-generated responses, then they are by default non-authoritative. At the least, I'd say this should be a configuration flag setting. Also, we use NXDOMAIN to reply to blocked queries. We would not want to look up or synthesize SOA for every zone in which a block is generated; that seems un-necessary. Also, what is the problem this patch is trying to solve?

@arjenz
Copy link
Contributor Author

arjenz commented Jun 12, 2019

I wasn't really solving an operational problem, I ran into dig output that looked odd, discussed a bit with @Habbie and back then we agreed it looked "weird" and might deserve an issue here. I agree that if we still want this (internally generated responses) it should be configurable.

@ashceryth
Copy link

ashceryth commented Jul 26, 2019

I built an ad blocking solution with dnsdist and would like dnsdist to return a SOA record telling me that the query has been blocked. Something like this:

;; AUTHORITY SECTION:
adserver.example.com.            300     IN      SOA     blocked. nobody.invalid. 1 3600 1200 604800 300

Is there currently any way to set the authority section of the answer when using a LuaAction?

@Habbie
Copy link
Member

Habbie commented Jul 26, 2019

I'm not sure that setting AUTHORITY is the right thing to do here on these responses. If these are internally-generated responses, then they are by default non-authoritative. At the least, I'd say this should be a configuration flag setting. Also, we use NXDOMAIN to reply to blocked queries. We would not want to look up or synthesize SOA for every zone in which a block is generated; that seems un-necessary. Also, what is the problem this patch is trying to solve?

Wisdom from https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-00:

If a policy rule matches and results in a modified answer, then that
modified answer will include in its additional section the SOA RR of
the policy zone whose rule was used to generate the modified answer.
This SOA RR includes the name of the DNS RPZ and the serial number of
the policy data which was connected to the DNS control plane when the
answer was modified.

@johnhtodd
Copy link

johnhtodd commented Jul 27, 2019

Habbie: So is the assertion that changing the SOA on RPZ or RPZ-like responses a desirable thing to do? I'm not clear on if your comments are in support of a Lua method to change SOA, or against it, or indicates desired change action associated with your comment as it relates to the ticket.

@zeha
Copy link
Collaborator

zeha commented Jul 27, 2019

I read this to mean: touching AUTHORITY isn't desirable, but there is precedent for adding a SOA in ADDITIONAL.

@johnhtodd
Copy link

johnhtodd commented Jul 27, 2019

Zeha: Adding the SOA doesn't seem to be a problem if it's optional, and customizable with a LuaAction. I can see how that would be useful.

@Habbie
Copy link
Member

Habbie commented Jul 27, 2019

So is the assertion that changing the SOA on RPZ or RPZ-like responses a desirable thing to do?

It was a data point; apparently putting a SOA in RPZ-based denials is what the RPZ spec wants.

I read this to mean: touching AUTHORITY isn't desirable, but there is precedent for adding a SOA in ADDITIONAL.

I totally skimmed over 'additional' there. Now I wonder what existing RPZ implementations do!

@ashceryth
Copy link

ashceryth commented Jul 29, 2019

I totally skimmed over 'additional' there. Now I wonder what existing RPZ implementations do!

I haven't tested it with BIND but it looks like it uses the ADDITIONAL section for the SOA. See the dig output here: https://abuse.ch/blog/using-urlhaus-as-response-policy-zone-rpz/

@rgacogne
Copy link
Member

rgacogne commented Aug 6, 2019

So let's say we want to generate an answer from dnsdist with a SOA record in ADDITIONAL, which seems doable. How do we generate the owner name from the query? Do we just chop off the first label of the qname? I'm worried it might be an issue in some cases since it might be taken as an indication that the zone exists while it might not.
Same question for the mname and the rname, although I'm not sure anyone really cares about those.

@Habbie
Copy link
Member

Habbie commented Aug 6, 2019

So let's say we want to generate an answer from dnsdist with a SOA record in ADDITIONAL, which seems doable. How do we generate the owner name from the query? Do we just chop off the first label of the qname? I'm worried it might be an issue in some cases since it might be taken as an indication that the zone exists while it might not.
Same question for the mname and the rname, although I'm not sure anyone really cares about those.

I have always assumed that this feature would involve the admin making these decisions consciously, with very little magic in dnsdist.

I note that in Knot Resolver, users are expected to type in such things in Lua strings as DNS wireformat, in fact.

@rgacogne
Copy link
Member

rgacogne commented Aug 6, 2019

That makes sense from Lua, but I can't really imagine a RCodeAction() rule and action per zone :-/

@Habbie
Copy link
Member

Habbie commented Aug 6, 2019

That makes sense from Lua, but I can't really imagine a RCodeAction() rule and action per zone :-/

in RPZ, the generated SOA is not a valid SOA for the response - it is only a debugging tool for finding out on whose authority (no pun intended) the block/change happened.

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

Successfully merging a pull request may close this issue.

7 participants