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

[arjenz]

• 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

3. > 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]

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]

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]

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]

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]

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]

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]

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

[johnhtodd]

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]

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]

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]

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]

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]

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

[Habbie]

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.