[Pdns-users] DiG _trace: no response, no fail, nothing

[stancs3]

I have seen this problem posted in various places over the years. It is
not clear if it is a bug, a bad config, or just non-functional.

My set up:

VM running Centos 7, up to date.
pdns install using postgresql db.
pdns-recursor install.

pdns is running as an authoritive ns, standalone, replicated via
postgresql to a second VM, pretty much identical.


pdns is set with recursor=local-address:5300

pdns-recursor is set with local-address equal to pdns local-address
above

pdns-recursor is set with local-port equal to pdns 5300 above.

It all seems to work.

The authoritive nameserver is private, and is populated with a few records which work.

The recursor is being tested with DiG. (and with typical surfing). I have verified that the VM has no other dns function working in parallel.

All DiG commands so far work with the exception of +trace.

I have logs running, and can easily see logs generated for DiG commands that work.

I have attached a console example. The logs and console indicate that the DiG command with +trace doesn't fail; it just doesn't even respond.

If I target the same DiG +trace command at my router's dnsmasq, it responds as expected with a whole bunch of trace info.

I have tried for days/hours with all variations I can think of and all manner of surfing for solutions. If there were failure logs it would help, but absolutely zero logs with the +trace command is issued to pdns. 

I have also dumped my cache and it has many NS records.

I am tempted to simply ignore this and just use the thing as it seems to work. I only tried DiG +trace to see how it all works......

[David]

Post by stancs3
I have seen this problem posted in various places over the years. It is
not clear if it is a bug, a bad config, or just non-functional.

https://github.com/PowerDNS/pdns/issues/4353

In your case (auth pointing to recursor) is a fairly broken config to
begin with, so this may be unlikely for you to get working. In order for
auth to respond to "NS ." without recursion you'd have to host the root
zone on there.

Recursor in front and forwarding your internal zones to auth would work
(most) of the time unless your cache doesn't have the root primed already.

Post by stancs3
VM running Centos 7, up to date.
pdns install using postgresql db.
pdns-recursor install.
pdns is running as an authoritive ns, standalone, replicated via
postgresql to a second VM, pretty much identical.
pdns is set with recursor=local-address:5300
pdns-recursor is set with local-address equal to pdns local-address
above
pdns-recursor is set with local-port equal to pdns 5300 above.
It all seems to work.
The authoritive nameserver is private, and is populated with a few records which work.
The recursor is being tested with DiG. (and with typical surfing). I have verified that the VM has no other dns function working in parallel.
All DiG commands so far work with the exception of +trace.
I have logs running, and can easily see logs generated for DiG commands that work.
I have attached a console example. The logs and console indicate that the DiG command with +trace doesn't fail; it just doesn't even respond.
If I target the same DiG +trace command at my router's dnsmasq, it responds as expected with a whole bunch of trace info.
I have tried for days/hours with all variations I can think of and all manner of surfing for solutions. If there were failure logs it would help, but absolutely zero logs with the +trace command is issued to pdns.
I have also dumped my cache and it has many NS records.
I am tempted to simply ignore this and just use the thing as it seems to work. I only tried DiG +trace to see how it all works......
_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[stancs3]

Thanks for the quick reply.

Yes, I did see this info at one point, and so I tried briefly to run
the recursor in front on its own, but I have not got it working yet.

Also,I did try the auth pdns as a recursor itself as I figured it
should work as an integrated server. But, I got the exact same results
- i.e. zero response to +trace.

   -------------------------------------------------

Stepping back, is it not a doable config to have a private auth server,
that hands off to a recursor, all internal, private?

If not, then at least I do need the auth server, so I can get basic
name serving for my internal network.

Would I then simply send all my recursive queries to my router's dns,
as is now the case? i.e. more nameservers listed in resov.conf of
clients.

Clearly neophyte questions re dns. Feel free to point me somewhere, but
so far all 'tutorials' have led me here.

The frustrating part is that most comprehensive dns documentation is
releative to BIND. I have been close to taking a break from pdns and
start over with BIND to learn things better. But, then pdns begins to
work so nicely it seems...... :). I hope to hear back ....


Stan

Post by David

Post by stancs3
I have seen this problem posted in various places over the years. It is
not clear if it is a bug, a bad config, or just non-functional.

https://github.com/PowerDNS/pdns/issues/4353
In your case (auth pointing to recursor) is a fairly broken config
to 
begin with, so this may be unlikely for you to get working. In order
for 
auth to respond to "NS ." without recursion you'd have to host the
root 
zone on there.
Recursor in front and forwarding your internal zones to auth
would  work 
(most) of the time unless your cache doesn't have the root primed already.

Post by stancs3
VM running Centos 7, up to date.
pdns install using postgresql db.
pdns-recursor install.
pdns is running as an authoritive ns, standalone, replicated via
postgresql to a second VM, pretty much identical.
pdns is set with recursor=local-address:5300
pdns-recursor is set with local-address equal to pdns local-address
above
pdns-recursor is set with local-port equal to pdns 5300 above.
It all seems to work.
The authoritive nameserver is private, and is populated with a few records which work.
The recursor is being tested with DiG. (and with typical surfing).
I have verified that the VM has no other dns function working in
parallel.
All DiG commands so far work with the exception of +trace.
I have logs running, and can easily see logs generated for DiG commands that work.
I have attached a console example. The logs and console indicate
that the DiG command with +trace doesn't fail; it just doesn't even
respond.
If I target the same DiG +trace command at my router's dnsmasq, it
responds as expected with a whole bunch of trace info.
I have tried for days/hours with all variations I can think of and
all manner of surfing for solutions. If there were failure logs it
would help, but absolutely zero logs with the +trace command is
issued to pdns.
I have also dumped my cache and it has many NS records.
I am tempted to simply ignore this and just use the thing as it
seems to work. I only tried DiG +trace to see how it all
works......
_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[stancs3]

Well, I managed to reverse the servers, and get them working.

DiG now works for +trace.

The auth server also seems to be working.

One new quirk:

DiG to my domain NS sends back the NS records but not the A records,
whereas all records came back when the auth server was on top.

But the auth nameserver seems to still work, as I can ping at the
client level using the host name that is defined in the A record in the
auth server.

Not sure if this is pointing to another problem, or it is simply
working.


Stan

Post by stancs3
Thanks for the quick reply.
Yes, I did see this info at one point, and so I tried briefly to run
the recursor in front on its own, but I have not got it working yet.
Also,I did try the auth pdns as a recursor itself as I figured it
should work as an integrated server. But, I got the exact same
results
- i.e. zero response to +trace.
   -------------------------------------------------
Stepping back, is it not a doable config to have a private auth server,
that hands off to a recursor, all internal, private?
If not, then at least I do need the auth server, so I can get basic
name serving for my internal network.
Would I then simply send all my recursive queries to my router's dns,
as is now the case? i.e. more nameservers listed in resov.conf of
clients.
Clearly neophyte questions re dns. Feel free to point me somewhere, but
so far all 'tutorials' have led me here.
The frustrating part is that most comprehensive dns documentation is
releative to BIND. I have been close to taking a break from pdns and
start over with BIND to learn things better. But, then pdns begins to
work so nicely it seems...... :). I hope to hear back ....
Stan

Post by David

Post by stancs3
I have seen this problem posted in various places over the years. It is
not clear if it is a bug, a bad config, or just non-functional.

https://github.com/PowerDNS/pdns/issues/4353
In your case (auth pointing to recursor) is a fairly broken config
to 
begin with, so this may be unlikely for you to get working. In order
for 
auth to respond to "NS ." without recursion you'd have to host the
root 
zone on there.
Recursor in front and forwarding your internal zones to auth
would  work 
(most) of the time unless your cache doesn't have the root primed already.

Post by stancs3
VM running Centos 7, up to date.
pdns install using postgresql db.
pdns-recursor install.
pdns is running as an authoritive ns, standalone, replicated via
postgresql to a second VM, pretty much identical.
pdns is set with recursor=local-address:5300
pdns-recursor is set with local-address equal to pdns local-
address
above
pdns-recursor is set with local-port equal to pdns 5300 above.
It all seems to work.
The authoritive nameserver is private, and is populated with a
few
records which work.
The recursor is being tested with DiG. (and with typical
surfing).
I have verified that the VM has no other dns function working in
parallel.
All DiG commands so far work with the exception of +trace.
I have logs running, and can easily see logs generated for DiG commands that work.
I have attached a console example. The logs and console indicate
that the DiG command with +trace doesn't fail; it just doesn't even
respond.
If I target the same DiG +trace command at my router's dnsmasq, it
responds as expected with a whole bunch of trace info.
I have tried for days/hours with all variations I can think of and
all manner of surfing for solutions. If there were failure logs it
would help, but absolutely zero logs with the +trace command is
issued to pdns.
I have also dumped my cache and it has many NS records.
I am tempted to simply ignore this and just use the thing as it
seems to work. I only tried DiG +trace to see how it all
works......
_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[stancs3]

OK, I managed to get DiG to respond with A records, but only by
specifying the hostname in from of the domain name. This is OK, but
when the servers where reversed, a simple DiG NS would return the NS
records, *and* the A records.

Again not a showstopper unless it points to config still broken.

I won't send any more emails tonight unless I have a major breakthru.

stna

Post by stancs3
Well, I managed to reverse the servers, and get them working.
DiG now works for +trace.
The auth server also seems to be working.
DiG to my domain NS sends back the NS records but not the A records,
whereas all records came back when the auth server was on top.
But the auth nameserver seems to still work, as I can ping at the
client level using the host name that is defined in the A record in the
auth server.
Not sure if this is pointing to another problem, or it is simply
working.
Stan

Post by stancs3
Thanks for the quick reply.
Yes, I did see this info at one point, and so I tried briefly to run
the recursor in front on its own, but I have not got it working yet.
Also,I did try the auth pdns as a recursor itself as I figured it
should work as an integrated server. But, I got the exact same results
- i.e. zero response to +trace.
   -------------------------------------------------
Stepping back, is it not a doable config to have a private auth server,
that hands off to a recursor, all internal, private?
If not, then at least I do need the auth server, so I can get basic
name serving for my internal network.
Would I then simply send all my recursive queries to my router's dns,
as is now the case? i.e. more nameservers listed in resov.conf of
clients.
Clearly neophyte questions re dns. Feel free to point me somewhere, but
so far all 'tutorials' have led me here.
The frustrating part is that most comprehensive dns documentation is
releative to BIND. I have been close to taking a break from pdns and
start over with BIND to learn things better. But, then pdns begins to
work so nicely it seems...... :). I hope to hear back ....
Stan

Post by David

Post by stancs3
I have seen this problem posted in various places over the
years.
It is
not clear if it is a bug, a bad config, or just non-functional.

https://github.com/PowerDNS/pdns/issues/4353
In your case (auth pointing to recursor) is a fairly broken config
to 
begin with, so this may be unlikely for you to get working. In order
for 
auth to respond to "NS ." without recursion you'd have to host the
root 
zone on there.
Recursor in front and forwarding your internal zones to auth
would  work 
(most) of the time unless your cache doesn't have the root primed already.

Post by stancs3
VM running Centos 7, up to date.
pdns install using postgresql db.
pdns-recursor install.
pdns is running as an authoritive ns, standalone, replicated via
postgresql to a second VM, pretty much identical.
pdns is set with recursor=local-address:5300
pdns-recursor is set with local-address equal to pdns local-
address
above
pdns-recursor is set with local-port equal to pdns 5300 above.
It all seems to work.
The authoritive nameserver is private, and is populated with a
few
records which work.
The recursor is being tested with DiG. (and with typical
surfing).
I have verified that the VM has no other dns function working in
parallel.
All DiG commands so far work with the exception of +trace.
I have logs running, and can easily see logs generated for DiG
commands that work.
I have attached a console example. The logs and console
indicate
that the DiG command with +trace doesn't fail; it just doesn't even
respond.
If I target the same DiG +trace command at my router's dnsmasq, it
responds as expected with a whole bunch of trace info.
I have tried for days/hours with all variations I can think of and
all manner of surfing for solutions. If there were failure logs it
would help, but absolutely zero logs with the +trace command is
issued to pdns.
I have also dumped my cache and it has many NS records.
I am tempted to simply ignore this and just use the thing as it
seems to work. I only tried DiG +trace to see how it all
works......
_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[stancs3]

Reverse doesn't work in this config, so I figure on giving up on
recursor.

An auth ns was my goal, so I am happy that pdns works forward and
reverse, and poweradmin makes it easy to manage.

I can either use my router's recursor, or perhaps set up a pdns-
recursor on a different VM to keep it clean. Wouldn't that be the
same/better than the router's?


That's it for now.

Thanks, if you read these emails.

Stan

Post by stancs3
OK, I managed to get DiG to respond with A records, but only by
specifying the hostname in from of the domain name. This is OK, but
when the servers where reversed, a simple DiG NS would return the NS
records, *and* the A records.
Again not a showstopper unless it points to config still broken.
I won't send any more emails tonight unless I have a major breakthru.
stna

Post by stancs3
Well, I managed to reverse the servers, and get them working.
DiG now works for +trace.
The auth server also seems to be working.
DiG to my domain NS sends back the NS records but not the A
records,
whereas all records came back when the auth server was on top.
But the auth nameserver seems to still work, as I can ping at the
client level using the host name that is defined in the A record in the
auth server.
Not sure if this is pointing to another problem, or it is simply
working.
Stan

Post by stancs3
Thanks for the quick reply.
Yes, I did see this info at one point, and so I tried briefly to run
the recursor in front on its own, but I have not got it working yet.
Also,I did try the auth pdns as a recursor itself as I figured it
should work as an integrated server. But, I got the exact same results
- i.e. zero response to +trace.
   -------------------------------------------------
Stepping back, is it not a doable config to have a private auth server,
that hands off to a recursor, all internal, private?
If not, then at least I do need the auth server, so I can get basic
name serving for my internal network.
Would I then simply send all my recursive queries to my router's dns,
as is now the case? i.e. more nameservers listed in resov.conf of
clients.
Clearly neophyte questions re dns. Feel free to point me
somewhere,
but
so far all 'tutorials' have led me here.
The frustrating part is that most comprehensive dns documentation is
releative to BIND. I have been close to taking a break from pdns and
start over with BIND to learn things better. But, then pdns
begins
to
work so nicely it seems...... :). I hope to hear back ....
Stan

Post by David

Post by stancs3
I have seen this problem posted in various places over the
years.
It is
not clear if it is a bug, a bad config, or just non-
functional.

https://github.com/PowerDNS/pdns/issues/4353
In your case (auth pointing to recursor) is a fairly broken config
to 
begin with, so this may be unlikely for you to get working. In order
for 
auth to respond to "NS ." without recursion you'd have to host the
root 
zone on there.
Recursor in front and forwarding your internal zones to auth
would  work 
(most) of the time unless your cache doesn't have the root
primed
already.

Post by stancs3
VM running Centos 7, up to date.
pdns install using postgresql db.
pdns-recursor install.
pdns is running as an authoritive ns, standalone, replicated via
postgresql to a second VM, pretty much identical.
pdns is set with recursor=local-address:5300
pdns-recursor is set with local-address equal to pdns local-
address
above
pdns-recursor is set with local-port equal to pdns 5300 above.
It all seems to work.
The authoritive nameserver is private, and is populated with a
few
records which work.
The recursor is being tested with DiG. (and with typical surfing).
I have verified that the VM has no other dns function working in
parallel.
All DiG commands so far work with the exception of +trace.
I have logs running, and can easily see logs generated for DiG
commands that work.
I have attached a console example. The logs and console indicate
that the DiG command with +trace doesn't fail; it just
doesn't
even
respond.
If I target the same DiG +trace command at my router's
dnsmasq,
it
responds as expected with a whole bunch of trace info.
I have tried for days/hours with all variations I can think
of
and
all manner of surfing for solutions. If there were failure
logs
it
would help, but absolutely zero logs with the +trace command is
issued to pdns.
I have also dumped my cache and it has many NS records.
I am tempted to simply ignore this and just use the thing as it
seems to work. I only tried DiG +trace to see how it all
works......
_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

_______________________________________________
Pdns-users mailing list
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Brian Candler]

Post by stancs3
Reverse doesn't work in this config, so I figure on giving up on
recursor.

What do you mean by "reverse doesn't work"? Can you give a specific
example of what you did, what you saw, and what you expected to see?

Reverse is just another domain (under in-addr.arpa), no different to any
other.

Post by stancs3
I can either use my router's recursor, or perhaps set up a pdns-
recursor on a different VM to keep it clean. Wouldn't that be the
same/better than the router's?

Most routers' built-in DNS is pretty poor - little more than a caching
forwarder to an upstream DNS (like dnsmasq), so having your own
pdns-recursor is likely to be much better.

If you want your authoritative DNS to be visible to the outside world
for real delegation, then it needs to listen on port 53. If you want
your recursive DNS to be usable by local clients, then it also needs to
listen on port 53, since most clients can't be (easily) configured to
send their DNS queries to a different port.

So, to run both auth and recursive, you need to assign two IP addresses.
Those can either be two different VMs (maximum separation), two
different containers, or even two different IPs in the same machine,
where the pns-auth and pdns-recursor processes are configured to bind to
(listen on) a different individual IP address.

You could try fancy tricks with dns-dist in front, but personally I'd
just go for the two VMs or two containers.

Don't forget redundancy. For authoritative DNS you'll want another
nameserver on a completely different backbone (see RFC2182). For client
redundancy, two local recursors is what you want.

HTH,

Brian.

[stancs3]

Many thanks for your comprehensive replies.

I have a number of paths to explore now and will head off to do some
more careful testing.

If I need further advice I will make sure to include a better set of
test results.

I certainly have more confidence in getting to a solution that works
for me, given the support of this forum.

Stan

Post by stancs3
Reverse doesn't work in this config, so I figure on giving up on
recursor.

What do you mean by "reverse doesn't work"? Can you give a specific 
example of what you did, what you saw, and what you expected to see?
Reverse is just another domain (under in-addr.arpa), no different to
any 
other.

Post by stancs3
I can either use my router's recursor, or perhaps set up a pdns-
recursor on a different VM to keep it clean. Wouldn't that be the
same/better than the router's?

Most routers' built-in DNS is pretty poor - little more than a
caching 
forwarder to an upstream DNS (like dnsmasq), so having your own 
pdns-recursor is likely to be much better.
If you want your authoritative DNS to be visible to the outside
world 
for real delegation, then it needs to listen on port 53. If you want 
your recursive DNS to be usable by local clients, then it also needs
to 
listen on port 53, since most clients can't be (easily) configured
to 
send their DNS queries to a different port.
So, to run both auth and recursive, you need to assign two IP
addresses. 
Those can either be two different VMs (maximum separation), two 
different containers, or even two different IPs in the same machine, 
where the pns-auth and pdns-recursor processes are configured to bind
to 
(listen on) a different individual IP address.
You could try fancy tricks with dns-dist in front, but personally
I'd 
just go for the two VMs or two containers.
Don't forget redundancy. For authoritative DNS you'll want another 
nameserver on a completely different backbone (see RFC2182). For
client 
redundancy, two local recursors is what you want.
HTH,
Brian.

[Brian Candler]

Post by stancs3
OK, I managed to get DiG to respond with A records, but only by
specifying the hostname in from of the domain name. This is OK, but
when the servers where reversed, a simple DiG NS would return the NS
records,*and* the A records.
Again not a showstopper unless it points to config still broken.

Do you mean that "dig foo" returns NXDOMAIN, but "ping foo" works
(resolving foo to the A record for foo.example.com)?

That's correct behaviour, and you should find it works if you do "dig
+search foo"

By default, the dig client by default does not use the search list in
/etc/resolv.conf, but normal DNS clients do.

nameserver x.x.x.x
search example.com

# Means: if I can't resolve foo them try adding example.com to the end

If you were able to do "dig foo" and got the answer previously, that
means your original nameserver configuration was completely broken - it
was answering queries for top-level name "foo." with data from elsewhere
in the DNS tree. So this is a good sign that you fixed things.

Pointing clients at the recursor, and having the recursor forward
specific domains to your internal authoritative DNS, is the right way to
do this.

Regards,

Brian.