Sure, but was a silly mistake I made,

Since I was testing on localhost over to another IP on the same machine, all the queries where going from the Local IP to loopback (even though I forced on the remotes flag w/ "via").

So all I had to do was actually serve everything through loopback (only different ports) to make things work.  

The debug showed the incoming query via 127.0.0.1:<randomport>

The wrong setup I made was:

Knotd listening on 192.168.0.1:53;
PowerDNS listening on 127.0.0.1:53;

PowerDNS couldn't talk to Knotd there, so I changed to:

Knotd listening on 127.0.0.1:53;
PowerDNS listening on 127.0.0.1:54;

And then they started talking AXFR properly

Since this is only a test setup to a larger scale migration I was just testing how AXFR performs w/ tons of data to load (250mb of zone files) and frequent updates that I was running in the same virtual machine. 

BTW, is a good practice to use the zones over tmpfs or since the knotd already throw everything at RAM on the runtime I don't need it?

I didn't liked the load times (but I do understand the existence of knotc and why I should not keep "restarting" knotd). 

On Tue, Jul 7, 2015 at 4:34 PM, Ondřej Surý <ondrej.sury@nic.cz> wrote:
Hi Filipe,

could you share your findings? We would like to know what was the solution if another user happens to have the same problem.

Feel free to share them in private if you don't want to do that publicly.

Cheers,
--
 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>
To: "Ondřej Surý" <ondrej.sury@nic.cz>
Cc: knot-dns-users@lists.nic.cz
Sent: Tuesday, July 7, 2015 9:26:03 PM

Subject: Re: [knot-dns-users] AXFR - RFC1912
Oh I made it work after debugging enough I could get the info needed. 
Without debug is very hard to understand why AXFR fails, it only returns "connection refused".

Thanks for the attention anyway :)  

On Tue, Jul 7, 2015 at 3:10 PM, Ondřej Surý <ondrej.sury@nic.cz> wrote:
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
> > _______________________________________________
> > knot-dns-users mailing list
> > knot-dns-users@lists.nic.cz
> > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

_______________________________________________
knot-dns-users mailing list
knot-dns-users@lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users



--
[ ]'s

Filipe Cifali Stangler

_______________________________________________
knot-dns-users mailing list
knot-dns-users@lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users



--
[ ]'s

Filipe Cifali Stangler




--
[ ]'s

Filipe Cifali Stangler