Re: [Pdns-users] reverse zone /27 subnet - migrating from bind

2019-01-24 Thread Andy Smith
On Fri, Jan 25, 2019 at 04:58:38AM +, Andy Smith wrote:
> I have not had any issues putting these zones into PowerDNS.

Having said that, I've never used zone2sql to do it, so it's
possible that tool does not work for reverse zones that aren't on an
octet boundary.

By way of example, I (in the ISP role) delegate 85.119.82.118/32 to
an end user by putting the equivalent of:

118-32  NS  ns1.abominable.org.uk.
118-32  NS  ns2.abominable.org.uk.
118 CNAME   118.118-32.82.119.85.in-addr.arpa.

into the zone 82.119.85.in-addr.arpa. So they have been delegated
the zone "118-32.82.119.85.in-addr.arpa". In their zone they
(apparently) have put the equivalent of:

118 PTR diablo.404.cx.

As you already saw, RFC2317 has a few different suggestions for how
to structure it, and there's also:

https://dougbarton.us/DNS/2317.html

Cheers,
Andy
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] reverse zone /27 subnet - migrating from bind

2019-01-24 Thread Andy Smith
Hi Martin,

On Thu, Jan 24, 2019 at 05:09:48PM +0100, Martin Kellermann via Pdns-users 
wrote:
> example: our ISP delegates the subnet 10.10.10.192/27 to our server as 
> primary NS.

What is the actual zone that the ISP has delegated to you? There are
a couple of variations in naming here, so you need to know. I have
not had any issues putting these zones into PowerDNS. They are zones
like any other, you just need to get the names right.

If you don't know the delegated name and you can't ask your ISP for
some reason, tell us one of the real IPs that works for reverse DNS
now. We can trace the delegation down from '.'.

Cheers,
Andy
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] reverse zone /27 subnet - migrating from bind

2019-01-24 Thread Martin Kellermann via Pdns-users
hi,
we're migrating from bind to powerdns and get confused about how to setup 
reverse delegation correctly, since subnets smaller /24 seems not to work out 
oft he box.

example: our ISP delegates the subnet 10.10.10.192/27 to our server as primary 
NS.

what ist he correct way to setup this reverse zone?

in bind we just used the zone 192.10.10.10.in-addr-arpa with PTRs from 193 to 
222 and it worked without problems.
the zone2sql tool converted this zone to powerdns, but it wasn't working as 
expected.
it seems that powerdns thinks 192.10.10.10.in-addr.arpa 10.10.10.192/32!
when changing the zone to 10.10.10.in-addr.arpa it works, but i think this 
means, powerdns manages this zone for 10.10.10.0/24 subnet not 10.10.10.192/27.

so i'm wondering, what ist he correct way to setup such a reverse zone in 
powerdns?

while searching for the right answer, i stumbled upon RFC2317 which from what i 
understand explaines how the ISPs have to setup their nameservers to provide 
subnets smaller than /24 to customers.
does this mean the in-addr.arpa lookups only works in /24 chunks?

regards.

MK
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


[Pdns-users] PowerDNS Recursor 4.1.10 Released

2019-01-24 Thread Erik Winkels
Hi,

We just released PowerDNS Recursor 4.1.10.

It fixes a bug where the recursor would not build when one had protobuf support 
disabled.  (So this release is only relevant for you if you're building the 
recursor from source (with protobuf disabled).)

The changelog[1]:

- #7403: Fix compilation in handleRunningTCPQuestion without protobuf 
support

The tarball[2] (signature[3]) is available at 
https://downloads.powerdns.com/releases/ and packages for CentOS 6 and 7, 
Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from 
https://repo.powerdns.com/ .

Please send us all feedback and issues you might have via the mailing list[4], 
or in case of a bug, via GitHub[5].

[1] https://doc.powerdns.com/recursor/changelog/4.1.html#change-4.1.10
[2] https://downloads.powerdns.com/releases/pdns-recursor-4.1.10.tar.bz2
[3] https://downloads.powerdns.com/releases/pdns-recursor-4.1.10.tar.bz2.sig
[4] https://mailman.powerdns.com/mailman/listinfo/pdns-users
[5] https://github.com/PowerDNS/pdns/issues/new
--
Erik Winkels
PowerDNS.COM BV -- https://www.powerdns.com


signature.asc
Description: PGP signature
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users


Re: [Pdns-users] Graphing as a service: Disappearing CPU graphs

2019-01-24 Thread bert hubert
On Wed, Jan 23, 2019 at 02:58:51PM +0100, sth...@nethelp.no wrote:
> - The User CPU% and System CPU% graphs sometimes disappear, after
> days/weeks of uptime. The *space* for the graphs (with legends for
> User CPU% blue and System CPU% red, on the right hand side) is still
> present but the graphs themselves are not shown.

Hi Steinar,

We've been corresponding a bit with you behind the scenes and "this should
not be happening". 

Your recursor reports spending the following amount of milliseconds on user
CPU time:

time_t  milliseconds
1547818832  301274008.418503
1547822864  301784302.665002
1547826896  302310096.107672
1547830928  302844638.859146
1547834960  303381189.070208
1547838992  303924399.662413
1547843024  304477529.572919
1547847056  305025750.193424
1547851088  305544141.140036
1547855120  306001630.092938
1547859152  306153010.535298
1547863184  306141696.00
1547867216  306141696.00
1547871248  306141696.00
1547875280  306141696.00
1547879312  306141696.00
1547883344  306141696.00
1547887376  306141696.00

Note that the number just stops increasing beyond 1547863184. The number 
306141696
does not appear to be magical in any kind of way.

We retrieve that number using the getrusage call which has seen some bugs on
FreeBSD. But this seems an odd bug. The ".00" is a bit suspicious
though.

So sadly, we are out of clue.

Bert

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