Saurabh: Not getting the answer with AAAA record. Error FORMERR resolving 'gim8.pl/AAAA/IN comes.

[Saurabh Srivastava]

Dear Bind-Users,

Greetings of the Day!!!

I have faced an issue on my RPZ Server.
I have added the A record Entry & AAAA record entry for some domains.
The RPZ Policy is running fine.
But the werired response that i am getting with few domains are that when I
have quered the A record for that domain, the answer is OK.
When I have quered for AAAA record, it is not given the answer.
When I have run the dig query using any option, it has shown me the A
record as well as AAAA record too.
I have facing this issue while querying following domains:
1. gim8.pl
2. ns-cnc1.qq.com
3. ns-tel1.qq.com

Lets take an example of first doamin:
I have sharing the dig o/p here with different options:
A. querying A Record:
-----------------------------
; <<>> DiG 9.10.3-P3 <<>> gim8.pl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19768
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gim8.pl. IN A

;; ANSWER SECTION:
gim8.pl. 5 IN A 10.40.124.13

;; AUTHORITY SECTION:
rpz.nkn.in. 3600 IN NS ns1.rpz.nkn.in.

;; ADDITIONAL SECTION:
ns1.rpz.nkn.in. 3600 IN A 10.199.88.2

;; Query time: 4406 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 22 17:22:57 IST 2018
;; MSG SIZE rcvd: 96

B: Query the AAAA Record:
-------------------------------------
; <<>> DiG 9.10.3-P3 <<>> gim8.pl AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gim8.pl. IN AAAA

;; Query time: 517 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 22 17:24:13 IST 2018
;; MSG SIZE rcvd: 36

C: Query the Record with ANY option:
--------------------------------------------------
; <<>> DiG 9.10.3-P3 <<>> gim8.pl any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 583
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gim8.pl. IN ANY

;; ANSWER SECTION:
gim8.pl. 5 IN AAAA 2001:4408:5240::13
gim8.pl. 5 IN A 10.40.124.13

;; AUTHORITY SECTION:
rpz.nkn.in. 3600 IN NS ns1.rpz.nkn.in.

;; ADDITIONAL SECTION:
ns1.rpz.nkn.in. 3600 IN A 10.199.88.2

;; Query time: 821 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 22 17:24:42 IST 2018
;; MSG SIZE rcvd: 124
Last o/p shows the AAAA record too...but alone its not working.

I am sharing you the messages that i received when I hit the AAAA query
using dig:
May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl/AAAA/IN':
104.130.132.112#53
May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl/AAAA/IN':
198.245.62.20#53
May 22 17:25:46 RPZ named[17245]: FORMERR resolving 'gim8.pl/AAAA/IN':
104.130.132.112#53
May 22 17:25:46 RPZ named[17245]: FORMERR resolving 'gim8.pl/AAAA/IN':
198.245.62.20#53


Can anyone suggest, what goes wrong & why the RPZ policy is not throuugh
the AAAA result when the dig alone run with AAAA query?


Thanks & Regards,

Saurabh Srivastava,
Mobile: [phone]
Email: ***@gmail.com

[Tony Finch]

Post by Saurabh Srivastava
I have faced an issue on my RPZ Server.
I have added the A record Entry & AAAA record entry for some domains.
The RPZ Policy is running fine.
But the werired response that i am getting with few domains are that when I
have quered the A record for that domain, the answer is OK.
When I have quered for AAAA record, it is not given the answer.
May 22 17:24:13 RPZ named[17245]: FORMERR resolving 'gim8.pl/AAAA/IN': 104.130.132.112#53

RPZ is a bit weird because it performs the query as usual, then applies
its rewrite rules. In this case, the original query fails, so there isn't
an AAAA in the answer to rewrite.

You can set the `qname-wait-recurse` option, so that RPZ will skip
recursion when it is able to rewrite a response based only on the query.
You might also want to set `break-dnssec` to make it ignore the DO bit.

If you are using `qname-wait-recurse`, you need to be careful about the
order of the policy zones listed in your RPZ clause so that it works as
expected: you should keep qname and client-ip triggers in separate zones,
and list those zones first - other RPZ rewrite rules force recursion to
happen.

The manual says the reason for this weird behaviour is: "not resolving the
requested name can leak the fact that response policy rewriting is in use
and that the name is listed in a policy zone to operators of servers for
listed names." If you are worried about that, it implies that (sadly) you
have an adversarial relationship with your users, since they are the only
people who can observe this information leak.

In my opinion your users should be able to trust you, so you should be
up-front about DNS rewriting, and you should explain to your users clearly
what your rewrite policy is. And if you have documented your policy,
there's no information leak because the information is in the documentation.

Tony.

[Tony Finch]

My understanding of why RPZ by default queries for names that it's going
to rewrite anyway, is that the lack of regular queries to the
authoritative servers alerts the zone owners (who we assume are
malicious or similar) to the fact that their zone is being blocked and
queries for it are being rewritten - thus encouraging them to move
sooner rather than later to a new name/zone.

Thinking about it further, the way this kind of leak can occur is if a
user visits a malicious web site which is only partially blocked; the bad
guys might then be able to work out that blocking has occurred - whether
by Safe Browsing blocks, or AV blocks, or RPZ blocks, etc. usw.

I think I prefer not to send traffic to malicious DNS servers if I can
avoid it, and rely on the threat intelligence bods to keep on top of
things (that's why we pay them the big bucks).

Tony.