[yadifa-users] Questions about 2.2.0's new multi-master feature

yadifa info at yadifa.eu
Tue Jul 19 16:11:17 CEST 2016


Dear Anand,

Thank you for your comments.

> the documentation is not clear about what yadifa considers to be failures.

We will improve the documentation, but please find already some clarification in this thread.

> 1. Does yadifa first do a query for the SOA record over UDP before it decides whether a zone transfer is needed, or does it immediately start a zone transfer over TCP regardless of the current state of the zone?

When YADIFA is started as a slave, a SOA check is done and compared with the files available on disk and will try to optimally load the zone. IXFR if possible and AXFR otherwise.

When a NOTIFY is received, YADIFA will first check the serial in the notification. If the serial is identical or lower, the notification is ignored.
If the serial is higher or not provided, the SOA record for the preferred primary name server is requested over UDP.  If the preferred primary has a higher serial, a zone transfer will be initiated, otherwise no transfer will be initiated at all.

> 2. If the SOA query times out (UDP packet loss), or the TCP connection for IXFR/AXFR times out, is that considered a failure? I assume so.

Yes.

> 3. If the TCP connection succeeds, but the primary responds with SERVFAIL, NOTIMP, NOTAUTH, etc, is that considered a failure or not?

Yes. Everything which will not result in a correct and complete transfer will be considered a failure.

> 4. If the TCP connection succeeds, and yadifa receives a zone transfer, but the TSIG digest doesn't match or the clocks are unsynchronised, is that considered a failure?

Yes. This will result in an incorrect transfer and hence will be considered a failure.

> 5. Is there any reason yadifa always uses the first primary upon notify?

We believe we have good reasons for always using the preferred primary and we have created a separate thread to elaborate on this question.
All comments related to when YADIFA will switch the preferred primary should be posted there.

Comments about what should (not) be considered a failure can be posted in this thread.

Kind regards,

R&D Team
EURid VZW

-----Original Message-----
From: yadifa-users [mailto:yadifa-users-bounces at mailinglists.yadifa.eu] On Behalf Of Anand Buddhdev
Sent: Friday, July 15, 2016 3:12 PM
To: yadifa-users at mailinglists.yadifa.eu
Cc: anandb at ripe.net
Subject: [yadifa-users] Questions about 2.2.0's new multi-master feature

Dear yadifa developers,

I've just read the documentation about yadifa 2.2.0's new multi-master feature, something I've been waiting for. However, the documentation is not clear about what yadifa considers to be failures.

The documentation says "If the preferred name server no longer answers, the next primary server in the list will be used."

I'd like to ask for details about the "no longer answers" part of that sentence. As you know, a primary may not answer for a number of reasons, or may answer with a response other than what yadifa may be expecting.
So here are my questions:

1. Does yadifa first do a query for the SOA record over UDP before it decides whether a zone transfer is needed, or does it immediately start a zone transfer over TCP regardless of the current state of the zone?

2. If the SOA query times out (UDP packet loss), or the TCP connection for IXFR/AXFR times out, is that considered a failure? I assume so.

3. If the TCP connection succeeds, but the primary responds with SERVFAIL, NOTIMP, NOTAUTH, etc, is that considered a failure or not?

4. If the TCP connection succeeds, and yadifa receives a zone transfer, but the TSIG digest doesn't match or the clocks are unsynchronised, is that considered a failure?

5. Is there any reason yadifa always uses the first primary upon notify?
I don't think that's a good design. If a zone has more than one master listed, then it is reasonable to assume that when a notify comes in, yadifa should promote that master to the preferred master, and XFR from it, because it has a newer copy of the zone. Otherwise, yadifa ends up trying to XFR multiple times, eg:

a) a zone has 2 masters, A and B
b) yadifa gets a NOTIFY from B
c) yadifa tries an XFR from A, but A hasn't updated yet, so no XFR happens
d) yadifa gets a NOTIFY from A, and does the XFR again, and succeeds this time, but it has wasted one XFR slot in step (c)

It would be nice if the documentation were clear on yadifa's zone refresh algorithm, as well as explain what precise cases are treated as failures (or not).

Regards,
Anand
_______________________________________________
yadifa-users mailing list
yadifa-users at mailinglists.yadifa.eu
http://www.yadifa.eu/mailman/listinfo/yadifa-users


More information about the yadifa-users mailing list