Unbound returns incorrect results

Unbound
1

Hi

My unbound returns incorrect results

Unboud returns .203 IP

suser@gong:~$ dig @1.204.196.202 www.mysite.net

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> @1.204.196.202 www.mysite.net

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2722

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.mysite.net. IN A

;; ANSWER SECTION:

www.mysite.net. 4275 IN CNAME mysite.net.

mysite.net. 5048 IN A 1.204.196.203

But my authoritative DNS server returns:

suser@gong:~$ dig @1.204.196.130 www.mysite.net

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> @1.204.196.130 www.mysite.net

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58582

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.mysite.net. IN A

;; ANSWER SECTION:

www.mysite.net. 10800 IN CNAME mysite.net.

mysite.net. 10800 IN A 1.2.25.159

;; AUTHORITY SECTION:

mysite.net. 10800 IN NS ns4.mysite.net.

mysite.net. 10800 IN NS ns1.mysite.net.

mysite.net. 10800 IN NS ns2.mysite.net.

;; ADDITIONAL SECTION:

ns1.mysite.net. 10800 IN A 1.204.196.130

ns2.mysite.net. 10800 IN A 1.2.25.199

ns4.mysite.net. 10800 IN A 1.204.196.200

;; Query time: 0 msec

;; SERVER: 1.204.196.130#53(1.204.196.130)

;; WHEN: Птн апр 17 15:30:39 EEST 2020

;; MSG SIZE rcvd: 178

and google returns correct records:

suser@gong:~$ dig @8.8.8.8 www.mysite.net

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> @8.8.8.8 www.mysite.net

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6220

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;www.mysite.net. IN A

;; ANSWER SECTION:

www.mysite.net. 1842 IN CNAME mysite.net.

mysite.net. 1842 IN A 1.2.25.159

;; Query time: 46 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Птн апр 17 15:30:05 EEST 2020

;; MSG SIZE rcvd: 76

This 1.204.196.203 was valid IP about half a year ago.

Can’t find where it comes from.

This is new clean unbound setup installed two days ago.

2

Hi,

Hi
My unbound returns incorrect results

Unboud returns .203 IP

Unbound looks up the target of the CNAME by itself, this is necessary
for security reasons for caching the correct data for that name. The
lookup for that returned the .203 IP. So that is the correct answer.

The original server was not returning the correct information. It must
return the same IP address for 'mysite.net' as when the DNS is queried
directly for the name. For security reasons, unbound queries for all
CNAME answers for the target name, to look it up directly, to make sure
it gets the correct information in cache.

In the print out you are missing a direct dig query for the 'mysite.net'
record, that would (apparantly because unbound finds it) return the .203
IP address. If I query for the names over here I get different results.
Since you say it was half a year ago .203, perhaps the .203 is still
there and returned for direct lookups for 'mysite.net' and this causes
it. If so, fix it so that the authoritative servers for 'mysite.net'
return the .203 answer for the name mysite.net.

Best regards, Wouter

3

Thanks for reply.
I see but this how looks query to mysite.net:

:~$ dig @1.204.196.130 mysite.net

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> @1.204.196.130 mysite.net

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4437

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;mysite.net. IN A

;; ANSWER SECTION:

mysite.net. 10800 IN A 1.2.25.159

;; AUTHORITY SECTION:

mysite.net. 10800 IN NS ns2.mysite.net.

mysite.net. 10800 IN NS ns4.mysite.net.

mysite.net. 10800 IN NS ns1.mysite.net.

;; ADDITIONAL SECTION:

ns1.mysite.net. 10800 IN A 1.204.196.130

ns2.mysite.net. 10800 IN A 1.2.25.199

ns4.mysite.net. 10800 IN A 1.204.196.200

;; Query time: 0 msec

;; SERVER: 1.204.196.130#53(1.204.196.130)

;; WHEN: Птн апр 17 15:59:26 EEST 2020

;; MSG SIZE rcvd: 160

cache returns
:~$ dig @1.204.196.202 mysite.net

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> @1.204.196.202 mysite.net

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2039

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;mysite.net. IN A

;; ANSWER SECTION:

mysite.net. 2298 IN A 1.204.196.203

;; Query time: 0 msec

;; SERVER: 1.204.196.202#53(1.204.196.202)

;; WHEN: Птн апр 17 16:11:35 EEST 2020

;; MSG SIZE rcvd: 58

My zone doesnt have this IP binded to 203

[root@ns1 named]# grep 203 mysite.net

forum IN A 1.204.196.203

lang IN A 1.204.196.203

Thanks in advance.

4

Hi,

So your server has the correct .159 answer for mysite.net. But unbound
must have had this lookup value from somewhere. That returned .203 and
is also a name server for mysite.net.

You can check the other nameservers for mysite.net for their response.
Or have unbound with verbosity 4 (or more) and that prints the
individual answers as unbound receives it. Start unbound again to make
it perform a new lookup and get the logs, then search for the .203
address and see where unbound got it from. (which is then one of the
nameservers for mysite.net).

Best regards, Wouter

5

Thanks Wouter, I’ve found issue.
Shame on me, there was rough/lost DNS server in network.

Thank you once more.

6

Юрий Иванов via Unbound-users writes:

> <site>
> ;; ANSWER SECTION:
> mysite.net. 10800 IN A 1.2.25.159
>
> ;; AUTHORITY SECTION:
> mysite.net. 10800 IN NS ns2.mysite.net.
> mysite.net. 10800 IN NS ns4.mysite.net.
> mysite.net. 10800 IN NS ns1.mysite.net.
>
> ;; ADDITIONAL SECTION:
> ns1.mysite.net. 10800 IN A 1.204.196.130
> ns2.mysite.net. 10800 IN A 1.2.25.199
> ns4.mysite.net. 10800 IN A 1.204.196.200
>

This is odd, becaause the nameservers should be:

; <<>> DiG 9.16.1 <<>> mysite.net ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25190
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
mysite.net. 324 IN NS authns1.untd.com.
mysite.net. 324 IN NS authns2.untd.com.
mysite.net. 324 IN NS authns3.untd.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 17 16:42:11 CEST 2020
;; MSG SIZE rcvd: 113

and
  for i in ` dig +short mysite.net ns `
  > do
  > dig +short $i a
  > done
  64.136.52.115
  64.136.44.115
  216.225.254.38

so you seem to do overwrite the official nameserver in you
configuration.

  jaap

7

Thanks Jaap,

All good.
I just change my real nameserver IP and domain names.
As I remember I should change to fake names and addresses before posting to mailgroup.

If this ok to share my real domain names I’ll post correct names in future. :wink:

8

What’s the point of redacting accurate information from the experts you are engaging while leaving the boxes on the internet for for the world to see and hackers to attack? It defies logic.

Jeff

9

My point is, I don’t want to be a person like - here my real servers, please resolve my issue I don’t want to thing myself.
Because of it I change my real names, not because of security.

Nevertheless I understand your point of view.

Next time I’ll don’t waste time to change real information.

10

My point is, I don't want to be a person like - here my real servers, please resolve my issue I don't want to thing myself.

I can't speak for others, but you would have gone to Stack Overflow for that :slight_smile:

Because of it I change my real names, not because of security.

Nevertheless I understand your point of view.
Next time I'll don't waste time to change real information.

Don't sweat it. I was poking some fun at you :slight_smile:

Jeff

11

With DNS problems it is often quicker to look up the name and see what
is wrong, than parse the email and try to figure it out from the information
that is included.

(And if something is changed because it is sensitive information, please
mention that, otherwise it wastes time of people trying to help :slight_smile: