Hello Kepi, thanks for replying!

I already made it work but thanks anyway, good to know more people using the same way we plan o using.

Regarding the performance, are you guys using regular FS to store or some kind of tmpfs/ramfs?

The startup is slow for lots of zones or I can improve it somehow?

On Fri, Jul 10, 2015 at 11:22 AM, Kepi <kepi@igloonet.cz> wrote:
Hi Filipe,

we have PowerDNS as master and Knot as slave, working without any
problem.

Your Knot setup seams similar to ours, w just dot have update-in master;
in zone but everything else is same. We also had problem with CNAMES
when we started to use Knot :) but that is fault of PowerDNS (or DNS
admins), not Knot.

Only thing which comes to my mind is if you have AXFR transfers allowed
in PowerDNS? You should have option

allow-axfr-ips=<ip of server with knot>

and maybe in your case with update-in you should also set

allow-dnsupdate-from=<ip of server with knot>

Both are probably allowing traffic from 127.0.0.1 if you have that enabled.

I kind of dont understand one thing in your setup. You have PowerDNS and
Knot on same server? hey are running on different ports or how this works?

Please cc me if you want my reaction, I'm not on the list currently.

--
Kepi

igloonet.cz | fb.com/igloonet

Ondřej Surý <ondrej.sury@nic.cz> writes:

> Also what does the Knot DNS logs say at debug level?
>
> We definitely have a user with similar setup (I'm Bccing him, so he
> can respond at his will) - PowerDNS as a primary and Knot DNS as a
> secondary.
>
> If you are into a deeper debugging, could you capture the packets
> between Knot secondary and PowerDNS primary?
>
> Cheers,
> Ondrej
> --
> Ondřej Surý -- Chief Science Officer
> --------------------------------------------
> CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.sury@nic.cz https://nic.cz/
> --------------------------------------------
>
> ----------------------------------------------------------------------
>
>     From: "Filipe Cifali" <cifali.filipe@gmail.com>
>     Cc: knot-dns-users@lists.nic.cz
>     Sent: Tuesday, July 7, 2015 5:41:17 PM
>     Subject: Re: [knot-dns-users] AXFR - RFC1912
>
>
>     Yes, w/ aa flag and all the SOA record
>
>
>
>
>     On Tue, Jul 7, 2015 at 12:12 PM, Jan Včelák <jan.vcelak@nic.cz>
>     wrote:
>
>     Hello Filipe,
>
>         does the PowerDNS server respond to SOA queries over TCP?
>
>         $ dig +tcp @127.0.0.1 zone.name SOA
>
>         Cheers,
>
>         Jan
>
>
>
>         On Tuesday, July 07, 2015 11:59:00 AM Filipe Cifali wrote:
>         > Thanks, I finished fixing all the zones now, finally.
>         >
>         > Anyone has ever used PowerDNS as master of a Knotd slave?
>         I'm missing
>         > something since PowerDNS returns connection refused after
>         the initial
>         > transfer, like it's not responding correctly to PowerDNS.
>         >
>         > Since I can dig AXFR @127.0.0.1 (which has PowerDNS running)
>         I don't see
>         > how he can be wrong.
>         >
>         > I'm not sure where to go looking for the problem here.
>         >
>         > Best Regards,
>         >
>         > [ ]'s
>         >
>         > On Thu, Jul 2, 2015 at 8:49 AM, Jan Včelák
>         <jan.vcelak@nic.cz> wrote:
>         > > Hello Filipe,
>         > >
>         > > On Thursday, July 02, 2015 07:57:46 AM Filipe Cifali
>         wrote:
>         > > > it's only failing for the zones w/ problems w/ CNAMEs,
>         ignoring the
>         > > > semantic-check off on the config.
>         > >
>         > > I have just taken a look to make sure: This particular
>         check is mandatory
>         > > and
>         > > cannot be disabled. And I'm quite sure I want to keep it
>         that way. The
>         > > CNAME
>         > > in apex is not allowed. And we would have to define some
>         behavior how to
>         > > answer when this happens, which makes a little sense.
>         > >
>         > > You should rather urge your clients to fix their zones
>         because this
>         > > problem
>         > > can lead to random resolution failures.
>         > >
>         > > Cheers,
>         > >
>         > > Jan



--
[ ]'s

Filipe Cifali Stangler