search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.72k stars 912 forks source link

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

Closed arjenz closed 4 years ago

arjenz commented 7 years ago

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: 1and 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))
  2. 
% 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 commented 6 years ago

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 :smiley:

johnhtodd commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

johnhtodd commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Habbie commented 5 years ago

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.