Discussion between Roman Bogachev and Håkan Lindqvist

Feeds

00:12

0

A: Local queries does not display domain records

Dnsdist will use the first matching action. With your config it will, depending on the source address, prefer the "recursor" pool, or otherwise use the "auth" pool. Ie, one or the other will be used to answer the current query, not some combination of the two. Based on the results, it sounds lik...

Roman Bogachev

I try to add forward-zones for pdns-recursor, but in this way recursor queries doesnt work and server cant resolv any domain.

Håkan Lindqvist

@RomanBogachev What specifically did you do and in what way did it not work?

Roman Bogachev

In pdns-recursor config i add forward-zones=google123.com=192.0.1.7. Now with @127.0.0.1 i get records of it domain, but servers which uses this dns server can`t resolv any domains.

Håkan Lindqvist

@RomanBogachev Can you clarify "can't resolve"? Dig output, maybe? Also, please add any relevant information to the question.

Roman Bogachev

In /etc/pdns-recursor/recursor.conf add forward-zones=example123.com=127.0.0.1:5300 restart pdns-recursor. After dig ANY example123.ru @192.0.1.7 at server in network 192.0.1.0/24 or at dns server dig ANY example123.ru @127.0.0.1 i ger records from Authoritative server. But if i ping any domain, i get error ping: example.com: Name or service not known.

Håkan Lindqvist

00:12

@RomanBogachev Is that equivalent to what these hosts normally do?

Roman Bogachev

I want that any server from recursive_ips can resolve any domains by recursor queries and can get records for domains at Authoritative server.

As it was in last version pdns with recursor at Authoritative server.

Håkan Lindqvist

But you said that this does work if you use dig from these hosts? Which makes me wonder if the problem is on the client side. Ie, stub resolver config

If you want something that will behave more closely to pdns-auth with recursor, I think the "making dnsdist always send queries for your zones directly to pdns-auth" would be it. Not that I know if this would solve your problem, considering it's somewhat unclear what exactly the problem is when using the abovementioned changes compared to the config in the question.

If you go with that approach, clients would get authoritative answers for your local zones, like they did before. Not that it's clear from the question that this would matter.

Roman Bogachev

Read my post. First message.
With this configs any domains at Authoritative servers doesnt show any records, if I use networks from recursive_ips:addMask

For example, I have:
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
192.168.4.0/24

From this network i doesnt see any records.
dig ANY example.com @127.0.0.1
or
dig ANY example.com @IP_OF_MY_DNS

But if I use any server out of this networks, works ACL 0.0.0.0/0 which forward queries to recursor and from internet i see records for domains at my Authoritative server.

Håkan Lindqvist

"After dig ANY example123.ru @192.0.1.7 at server in network 192.0.1.0/24 or at dns server dig ANY example123.ru @127.0.0.1 i ger records from Authoritative server." <--- this is what I'm referring to. That sounded like it did work?

And then "But if i ping any domain, i get error ping: example.com: Name or service not known." which suggests the problem may rather be with how the stub resolver on that host is configured? (Ie, ping using the stub resolver, in contrast to how you had dig query the nameserver directly)

Roman Bogachev

00:30

Yes, but servers on which in /etc/resovl.conf indicated
nameserver 192.0.1.7

Cant resolv any domains. And send alerts))

Works either one or the other, but not together

Håkan Lindqvist

Just to try to relate this back to the question, what is 192.0.1.7 in relation to the addresses mentioned in the question?

Afaict dnsdist is on 192.0.1.5?

Roman Bogachev

was entangled in renaming

There are two DNS servers:
NS1.EXAMPLE.COM - 192.168.1.5
NS2.EXAMPLE.COM - 192.168.2.5

SITE: EXAMPLE123.COM - 192.168.1.7

Allowed networks for recursion:
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
192.168.4.0/24

Håkan Lindqvist

00:46

Ok, so when you tested with dig from one of these clients it was @192.168.1.5 or what?

And that worked?

Roman Bogachev

Withe those configs:

From network
192.168.1.0/24 i use dig ANY example.com @192.168.1.5
192.168.2.0/24 i use dig ANY example.com @192.168.1.5
192.168.3.0/24 i use dig ANY example.com @192.168.1.5
192.168.4.0/24 i use dig ANY example.com @192.168.1.5

From server NS1.EXAMPLE.COM - 192.168.1.5 i use dig ANY example.com @127.0.0.1

Configs from one of them:

/etc/pdns-recursor/recursor.conf

setuid=pdns-recursor
setgid=pdns-recursor
local-address=127.0.0.1
local-port=5301
hint-file=/etc/pdns-recursor/root.zone
allow-from=127.0.0.0/8
/etc/pdns/pdns.conf

setuid=pdns
setgid=pdns
launch=gmysql
gmysql-host=127.0.0.1
gmysql-user=powerdns_user
gmysql-dbname=powerdns
gmysql-password=
allow-axfr-ips=127.0.0.0/8, 192.0.2.5/32
cache-ttl=60
control-console=no
default-soa-name=ns2.example.ru
[email protected]
default-ttl=3600

With those configs i get next answer

*FROM SERVER IN NETWORK 192.0.1.0/24*

# dig ANY google123.com @192.0.1.5

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> ANY google123.com @192.0.1.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54293
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
com. 2118 IN SOA a.dns.ripn.net. hostmaster.ripn.net. 4032536 86400 14400 2592000 3600

Håkan Lindqvist

I thought you said that after you added forward-zones=google123.com=192.0.1.7 (I guess actually 192.168.1.5 or something?) it worked when testing with dig?

Roman Bogachev

After i added forward-zones=google123.com=127.0.0.1:5300

From network
192.168.1.0/24 i use dig ANY example.com @192.168.1.5
192.168.2.0/24 i use dig ANY example.com @192.168.1.5
192.168.3.0/24 i use dig ANY example.com @192.168.1.5
192.168.4.0/24 i use dig ANY example.com @192.168.1.5

I can see records

But other servers from those network cant resolv any domains.

Håkan Lindqvist

And what happens on those other servers?

Roman Bogachev

They cant resolv any domains. Cant install updates/packets, use scripts, use domains at apps and etc

They didnt see inet)

Håkan Lindqvist

01:17

In terms of DNS, what happens? Do they use 192.168.1.5? What does 192.168.1.5 answer? Etc

I'm going to have to leave for tonight, but I would suggest that you add all the info into the question. If you are going with the forward-zones approach, do add dig output that shows the remaining problem (because it sounded like that solved the initial problem?)

And do make sure that all addresses etc are consistent, because it makes little sense to try to spot the error if the actual problem statement is accidentally inconsistent for whatever reason.

Roman Bogachev

Thank for help. I add information to answer. Good night)

Håkan Lindqvist

Good night

Roman Bogachev

01:32

Man...I found my problem)) I set 127.0.0.1/8 by force of habit but need 127.0.0.0/8 or 127.0.0.1/32
Now all works!

Roman Bogachev

08:28

But no. It was temporary. In the morning the problem reappeared. Hmmmm

Roman Bogachev

10:13

Problem solved)
I want sleep)

Transcript for

Discussion between Roman Bogachev and…