Opened 8 years ago

Closed 8 years ago

#1210 closed task (complete)

IXFR system test specification

Reported by: stephen Owned by: stephen
Priority: high Milestone: Sprint-20111011
Component: xfrin Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 6 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

Review RFC 1995 (the description of IXFR) and produce the specification for a set of system tests to check the implementation of IXFR-in and IXFR-out.

Subtickets

Change History (16)

comment:1 Changed 8 years ago by jelte

  • Estimated Difficulty changed from 0 to 6

comment:2 Changed 8 years ago by jelte

  • Milestone changed from Sprint-20110927 to Sprint-20111011

comment:3 Changed 8 years ago by jelte

  • Priority changed from major to critical

comment:4 Changed 8 years ago by stephen

  • Owner set to stephen
  • Status changed from new to accepted

comment:5 Changed 8 years ago by stephen

  • Owner changed from stephen to UnAssigned
  • Status changed from accepted to assigned

Specification is at IxfrSystemTests.

comment:6 Changed 8 years ago by stephen

  • Status changed from assigned to reviewing

comment:7 Changed 8 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:8 Changed 8 years ago by vorner

  • Owner changed from vorner to stephen

Hello

Should I read the RFC as well just to make sure you didn't miss anything as well?

It says the class must be IN. Does it mean we can't use IXFR for differnt class?

Why are the version numbers by tens? Isn't it enough to just miss the one single number that is not present?

You propose to use bind9 for the tests. Isn't it easier to prepare the packets to answer in some files and use socat for example to send/receive the packets?

The 4/4 says the order of changes is set. However, it also says the whole transaction is atomic. I think it refers to the effect on the resulting data in the zone. If we, for example, had a „delete this RR“ and then again „add this RR“, it results in a zone containing it. If it is the other way around, it results in a zone without. Maybe some data might test this?

For 4/7, can we simulate a TCP connection that gets truncated/reset? And see the data from the beginning didn't get stored?

Can we check that the IXFR is sent when the SOA times out? Or is that too long to test? Should we mention it?

Thanks

comment:9 follow-up: Changed 8 years ago by stephen

Should I read the RFC as well just to make sure you didn't miss anything as well?

Might be useful - it's a relatively short document.

It says the class must be IN. Does it mean we can't use IXFR for different class?

Good point. I've updated the requirements to remove reference to the IN class, but updated the test specification to indicate that the tests should carried out for each class. (And noted that at present, BIND 10 only supports class IN.)

Why are the version numbers by tens? Isn't it enough to just miss the one single number that is not present?

More that when I started writing the tests I was unsure whether I needed to be able to specify multiple serial numbers between the serial numbers of two versions, so left a gap of 10. Changes to be n-2, n-4, n-6.

You propose to use bind9 for the tests. Isn't it easier to prepare the packets to answer in some files and use socat for example to send/receive the packets?

The reason for BIND 9 is that this implicitly checks that the format of the request is correct. It also handles the generation of NOTIFY packets to the BIND 10 server that cause it to send the IXFR request. Also, by loading different versions of a zone, it is possible to generate difference packets without the need to explicitly create the binary data.

The 4/4 says the order of changes is set. However, it also says the whole transaction is atomic. I think it refers to the effect on the resulting data in the zone. If we, for example, had a „delete this RR“ and then again „add this RR“, it results in a zone containing it. If it is the other way around, it results in a zone without. Maybe some data might test this?

I noted that requirement because it is mentioned in RFC 1995. However, the only circumstance I can see in which it makes a difference is where the update comprises the deletion of a RR and the addition of an identical RR. Then the action depends on whether "delete this RR" means "delete all RRs in the zone identical to this RR". If so, we get the effect you describe. If not, and "delete this RR" means "delete the first RR matching this", it makes no difference.

Thoughts?

For 4/7, can we simulate a TCP connection that gets truncated/reset? And see the data from the beginning didn't get stored?

That is a test that needs to be done, but might involve a good deal of work to capture a binary data stream and replay it in response to an IXFR query from the client under test. tcpdump can be used to capture a data stream to a pcap file and I've found Wireplay to replay it back - although that needs investigation to see if it can replay with a (truncated) TCP stream in response to an IXFR query. Given the limited time available, I'm tempted to put this as a separate ticket.

Can we check that the IXFR is sent when the SOA times out? Or is that too long to test? Should we mention it?

Good point. We can do it by setting the SOA refresh time to a small value. I've added a requirement for it and a test.

Last edited 8 years ago by stephen (previous) (diff)

comment:10 Changed 8 years ago by stephen

  • Owner changed from stephen to vorner

comment:11 in reply to: ↑ 9 Changed 8 years ago by vorner

  • Owner changed from vorner to stephen

Hello

Replying to stephen:

Should I read the RFC as well just to make sure you didn't miss anything as well?

Might be useful - it's a relatively short document.

I didn't find anything you missed. The test specification could maybe be more explicit on when there are two SOA records in a row and when only one, but it does link to the type described in the RFC when needed, so it's not necessary.

You propose to use bind9 for the tests. Isn't it easier to prepare the packets to answer in some files and use socat for example to send/receive the packets?

The reason for BIND 9 is that this implicitly checks that the format of the request is correct. It also handles the generation of NOTIFY packets to the BIND 10 server that cause it to send the IXFR request. Also, by loading different versions of a zone, it is possible to generate difference packets without the need to explicitly create the binary data.

Well, on the other hand, Bind 9 might be wrong as well. Checking explicitly might be useful in some of the tests. But it is true that creating the binary data might take some work (as well as launching bind 9 on the other hand). I just wanted to point out another possibility.

The 4/4 says the order of changes is set. However, it also says the whole transaction is atomic. I think it refers to the effect on the resulting data in the zone. If we, for example, had a „delete this RR“ and then again „add this RR“, it results in a zone containing it. If it is the other way around, it results in a zone without. Maybe some data might test this?

I noted that requirement because it is mentioned in RFC 1995. However, the only circumstance I can see in which it makes a difference is where the update comprises the deletion of a RR and the addition of an identical RR. Then the action depends on whether "delete this RR" means "delete all RRs in the zone identical to this RR". If so, we get the effect you describe. If not, and "delete this RR" means "delete the first RR matching this", it makes no difference.

Thoughts?

Well, can a zone contain multiple RRs with the exactly same data? If not, the „addition“ of the same data would be NOP (since the zone would be kind of set, not zone and such RR would be already there).

Anyway, can we add a test with this kind of data?

Thanks

comment:12 follow-up: Changed 8 years ago by stephen

  • Owner changed from stephen to vorner

Well, can a zone contain multiple RRs with the exactly same data? If not, the „addition“ of the same data would be NOP (since the zone would be kind of set, not zone and such RR would be already there).

Considering the recent discussions on bind10-dev, apparently not. (Or at least, the zone should not contain multiple RRs with exactly the same data.)

For that reason, I think a test in the presence of multiple identical RRs would have little point as we would be testing behaviour in the presence of a behaviour which is incorrect (it is against RFC 2181) and which we want to eliminate.

comment:13 in reply to: ↑ 12 Changed 8 years ago by vorner

  • Owner changed from vorner to stephen

Hello

Replying to stephen:

Well, can a zone contain multiple RRs with the exactly same data? If not, the „addition“ of the same data would be NOP (since the zone would be kind of set, not zone and such RR would be already there).

Considering the recent discussions on bind10-dev, apparently not. (Or at least, the zone should not contain multiple RRs with exactly the same data.)

For that reason, I think a test in the presence of multiple identical RRs would have little point as we would be testing behaviour in the presence of a behaviour which is incorrect (it is against RFC 2181) and which we want to eliminate.

I believe we didn't understand each other correctly. I do not propose to explicitly put multiple same RRs into the zone. I propose to:

  • Put www.example.org. A 192.0.2.1 into the zone.
  • Apply diff:
    - www.example.org. A 192.0.2.1
    + www.example.org. A 192.0.2.1
    

This is completely correct, even if it is NOP. This way, the only instance is removed first and then returned again. The result is we get the original data in the zone.

If the additions would be applied first (the wrong behaviour), we would get a zone with two identical records, which is wrong by itself. But they would either get collapsed to single one, or the remove would delete both, so we would detect a wrong (empty) zone.

And I got another idea where the order might matter. What should we do if we are asked to remove an RR that is not in the zone? If we have an empty zone and the same diff arrives, we should first apply the remove (which does nothing), then add the single record. If it would be the other way around, it would be first added and then removed, resulting in empty zone.

Is what I mean little bit more clearer?

Thanks

comment:14 follow-up: Changed 8 years ago by stephen

  • Owner changed from stephen to vorner

OK, understand you now.

Of course, a difference sequence that deletes and adds the same RR should not be seen in real life, although I can't see anywhere in RFC 1995 where is is prohibited. And one that deletes a non-existent RR should trigger an error as it implies that the sender's copy of a particular version of the zone is not the same as the receiver's copy of that version.

For the second reason I've added a new (and what seems to be reasonable) requirement (A/2) that requires that the server reject an IXFR in that circumstance.

I've added some more tests to check the response to those particular packets.

comment:15 in reply to: ↑ 14 Changed 8 years ago by vorner

  • Owner changed from vorner to stephen

Hello

Replying to stephen:

Of course, a difference sequence that deletes and adds the same RR should not be seen in real life, although I can't see anywhere in RFC 1995 where is is prohibited. And one that deletes a non-existent RR should trigger an error as it implies that the sender's copy of a particular version of the zone is not the same as the receiver's copy of that version.

OK, makes sense. I think we can call this complete for now.

I'd point out that current implementation probably will not comply with the raising of an error, such change will simply be ignored, as it is not checked at all. And maybe the server could retry with AXFR to fix the inconsistent data, but let's talk about it when we're there.

With regards

comment:16 Changed 8 years ago by stephen

  • Resolution set to complete
  • Status changed from reviewing to closed
Note: See TracTickets for help on using tickets.