Why does my nameserver (BIND) return wrong answers?

Lockywolf · 02-11-2017, 05:52 AM

Hello, everyone.

I apologize in advance if this question belongs to the "Security" subforum.

My problem is the following:

I have a caching/recursive named server, running on my home router.

It is told to forward all the queries to traverse the DNS tree by itself.

However, when I query certain domains, I receive the following answer:

Code:

root@server:~# dig youporn.com  +trace +dnssec  +all

; <<>> DiG 9.10.4-P4 <<>> youporn.com +trace +dnssec +all
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48649
;; flags: qr ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 19

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       408430  IN      NS      b.root-servers.net.
.                       408430  IN      NS      l.root-servers.net.
.                       408430  IN      NS      g.root-servers.net.
.                       408430  IN      NS      c.root-servers.net.
.                       408430  IN      NS      e.root-servers.net.
.                       408430  IN      NS      a.root-servers.net.
.                       408430  IN      NS      k.root-servers.net.
.                       408430  IN      NS      i.root-servers.net.
.                       408430  IN      NS      h.root-servers.net.
.                       408430  IN      NS      d.root-servers.net.
.                       408430  IN      NS      m.root-servers.net.
.                       408430  IN      NS      j.root-servers.net.
.                       408430  IN      NS      f.root-servers.net.
.                       517947  IN      RRSIG   NS 8 0 518400 20170224050000 20170211040000 61045 . WNad6q/DOn0VpzCf0jjMjIbD+b3r7nhqc8iUY134+tZhtjhTlzf5wib6 qqF9alfDN3cBB0osBNmjjGYzecasZG55BVBee6KdmA8mbuLcRtV2ZRts /FkjYJ3KF7ECe3W4pnvo642oG58tB3nbPOPhuVyVRzRnjsXWJOwUynhg lO7YEUX4Bbhdv+RPgi8O//AVoqdr967s6nNpXzY09A9hmLyt2eifDBax k/+HOPo/sLMqVe/fc4J37jf4uZnOv5ogoSyTnP8nn0FhTekWc0HuRNuG 1WTQ0XJRwv+WDzdp/t/cFu/yGq0/KZBOtsWOuszRBjYSqF+u1LEjwkPG xfm9og==

;; ADDITIONAL SECTION:
a.ROOT-SERVERS.net.     600587  IN      A       198.41.0.4
b.ROOT-SERVERS.net.     600587  IN      A       192.228.79.201
c.ROOT-SERVERS.net.     600587  IN      A       192.33.4.12
d.ROOT-SERVERS.net.     600588  IN      A       199.7.91.13
f.ROOT-SERVERS.net.     600585  IN      A       192.5.5.241
g.ROOT-SERVERS.net.     600588  IN      A       192.112.36.4
h.ROOT-SERVERS.net.     600585  IN      A       198.97.190.53
i.ROOT-SERVERS.net.     600588  IN      A       192.36.148.17
j.ROOT-SERVERS.net.     600587  IN      A       192.58.128.30
k.ROOT-SERVERS.net.     600587  IN      A       193.0.14.129
l.ROOT-SERVERS.net.     600587  IN      A       199.7.83.42
m.ROOT-SERVERS.net.     600588  IN      A       202.12.27.33
a.ROOT-SERVERS.net.     488493  IN      AAAA    2001:503:ba3e::2:30
d.ROOT-SERVERS.net.     488493  IN      AAAA    2001:500:2d::d
f.ROOT-SERVERS.net.     488493  IN      AAAA    2001:500:2f::f
g.ROOT-SERVERS.net.     359045  IN      AAAA    2001:500:12::d0d
k.ROOT-SERVERS.net.     488493  IN      AAAA    2001:7fd::1
l.ROOT-SERVERS.net.     488493  IN      AAAA    2001:500:9f::42

;; Query time: 0 msec
;; SERVER: 192.168.3.1#53(192.168.3.1)
;; WHEN: Сб фев 11 14:46:04 MSK 2017
;; MSG SIZE  rcvd: 922

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42388
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Message has 4 extra bytes at end

;; QUESTION SECTION:
;youporn.com.                   IN      A

;; ANSWER SECTION:
youporn.com.            1026    IN      A       213.167.39.27

;; Query time: 1 msec
;; SERVER: 199.7.91.13#53(199.7.91.13)
;; WHEN: Сб фев 11 14:46:04 MSK 2017
;; MSG SIZE  rcvd: 49

root@server:~#

I don't understand this answer.

Yes, I do know that my ISP is filtering DNS requests.

But anyway, I am expecting to see root-servers.org forwarding me to the gtld-servers.org, having the answer signed with the root's private key.

Whereas here I see the answer returned directly from the root-servers, and no SERVFAIL.

What happens here?

Lockywolf · 02-11-2017, 06:09 AM

Also, if I set +aaonly calling dig, everything is resolved correctly.

Why does my BIND cache bogus replies?

Habitual · 02-11-2017, 07:52 AM

Try

Code:

service bind9 restart && rndc reload

after the edit and before a new dig command?

Lockywolf · 02-11-2017, 09:55 AM

Nope, restarting named doesn't help.

I still only get correct resolving if I put +trace +aaonly at the end of the dig command.

bathory · 02-12-2017, 04:07 AM

Quote:

root@server:~# dig youporn.com +trace +dnssec +all
<-snip->
;; ANSWER SECTION:
youporn.com. 1026 IN A 213.167.39.27

I don't understand this answer.

Yes, I do know that my ISP is filtering DNS requests.

Yous ISP does some sort of content filtering.
When visiting 213.167.39.27 with a browser I get a russian text, that translated gives:

Quote:

restricted

Dear subscriber, access to the requested resource is blocked by the decision of state authorities.

Based on the Decree of the RF Government dated October 26, 2012 №1101 and in accordance with Articles №9 and №15.1. Federal Law of July 27, 2016 № 149-FZ "On information, information technologies and information protection", this resource contains information the dissemination of which is prohibited in the Russian Federation!

Regards

Lockywolf · 02-12-2017, 04:27 AM

Quote:

Originally Posted by bathory

Yous ISP does some sort of content filtering.
When visiting 213.167.39.27 with a browser I get a russian text, that translated gives:

Regards

Yes, it does! I know!

That's why I installed my own BIND in the first place!

But the thing is, I expect the ISP to be unable to hijack the answers from the root servers, as they are expected to be signed with DNSSEC!

I expected to only see the last step in the trace hijacked. (Since youporn's domain itself is not signed with DNSSEC.)

But I don't see that! It looks as if the wrong answer comes from the root servers itself, whereas it should have failed the validation by the root trust anchors.