The Subpartitioning Process

After all the graph manipulation has been completed as described in the partitioning section, we would normally have a series of system/interface groups ready to transform into <SYSTEM> elements. Most of the time the process is straightforward, but sometimes there are complications.

The Problem

Take, for instance, the following (pseudo)DNS data. It is almost identical to the original example, but the few differences (in bold) are enough to illustrate the potential problem.

; Example DNS Data

a  IN    A       1
a  IN    A       2 
a  IN    CNAME   x
b  IN    A       3
b  IN    A       4
c  IN    A       1
d  IN    A       2
d  IN    A       5

1  IN    PTR     a 
2  IN    PTR     a
3  IN    PTR     b
4  IN    PTR     b
5  IN    PTR     d

Again, we convert from directed to undirected...

...and separate out the connected components:

System B is the same as in the original example, so we'll just focus on System A:

It is finally at this point that we can see the problem. Here a will be chosen as the system because it has the most A and PTR resource records associated with it. Previously, we would take it for granted that the interfaces 1, 2, and 5 were interfaces of a and that c and d were just alternate names for those interfaces. This time, however, it's not that simple.

It can be seen that d is connected (in the graph) to a since they share interface 2. For that reason it is included as part of this connected component. Interface 5, in turn, is connected to d, so as expected, interface 5 is also part of this connected component. The problem is that interface 5 is NOT an interface of our system, a. The xml generated from this configuration would be incorrect:

<SYSTEM>

  <DNS NAME="a">           <-- 'a' was determined to be the system
    <ALIAS>x</ALIAS>       <-- representing      x  IN  CNAME  a
  </DNS>

  <INTERFACE>
    <DNS NAME="c"></DNS>   <-- representing      c  IN  A      1
    <IP ADDR="1">              (and implicitly)  a  IN  A      1
      <PTR>a</PTR>         <-- representing      1  IN  PTR    a
    </IP>
  </INTERFACE>

  <INTERFACE>
    <DNS NAME="d"></DNS>   <-- representing      d  IN  A      2
    <IP ADDR="2">              (and implicitly)  a  IN  A      2
      <PTR>a</PTR>         <-- representing      2  IN  PTR    a
    </IP>
  </INTERFACE>

  <INTERFACE>
    <DNS NAME="d"></DNS>   <-- representing      d  IN  A      5
    <IP ADDR="5">              (and implicitly)  a  IN  A      5 <-- WRONG!!!
      <PTR>d</PTR>         <-- representing      5  IN  PTR    d
    </IP>
  </INTERFACE>

</SYSTEM>

The xml encodes an

'a  IN  A   5'
resource record which does not exist in the original data.

Hopefully, this data fragment is enough to illustrate the problem. Situations like this may be improbable, perhaps just the result of incorrect DNS data in the zone files. There may be, however, some valid reason for configuring data like this. Either way, the point is that this situation can occur as a result of the decision to organize the DNS data in terms of <SYSTEM> and <INTERFACE> elements, and the means by which this organization is accomplished. The next section describes how it is solved.

The Solutions

There are three reasonable ways to deal with the problem.

Solution 1 - Ignore the Problem

Just ignoring the problem actually results in incomplete data, so dns2xml won't allow this option. It requires one of the following two solutions when faced with this situation.

Solution 2 - Unique IPs

We say that the DNS name of an interface of one <SYSTEM> can have the same name as an entirely different <SYSTEM>, but interfaces can't overlap between the two systems:

<SYSTEM>

  <DNS NAME="a">           <-- 'a' was determined to be the system
    <ALIAS>x</ALIAS>       <-- representing      x  IN  CNAME  a
  </DNS>

  <INTERFACE>
    <DNS NAME="c"></DNS>   <-- representing      c  IN  A      1
    <IP ADDR="1">              (and implicitly)  a  IN  A      1
      <PTR>a</PTR>         <-- representing      1  IN  PTR    a
    </IP>
  </INTERFACE>

  <INTERFACE>
    <DNS NAME="d"></DNS>   <-- representing      d  IN  A      2
    <IP ADDR="2">              (and implicitly)  a  IN  A      2
      <PTR>a</PTR>         <-- representing      2  IN  PTR    a
    </IP>
  </INTERFACE>

</SYSTEM>

<SYSTEM>

  <DNS NAME="d"></DNS>     <-- 'd' is the only choice, so definitely the system
  
  <INTERFACE>
    <IP ADDR="5">          <-- representing      d  IN  A      5
      <PTR>d</PTR>         <-- representing      5  IN  PTR    d
    </IP>
  </INTERFACE>

</SYSTEM>

All the correct resource records will be generated from the above xml.

Solution 3 - Unique DNS Names

This is the converse of solution 2. We say that an interface (IP address) that appears in one <SYSTEM> can also appear in other <SYSTEM> elements, but that the uniqueness of DNS names between systems must be maintained:

<SYSTEM>

  <DNS NAME="a">           <-- 'a' was determined to be the system
    <ALIAS>x</ALIAS>       <-- representing      x  IN  CNAME  a
  </DNS>

  <INTERFACE>
    <DNS NAME="c"></DNS>   <-- representing      c  IN  A      1
    <IP ADDR="1">              (and implicitly)  a  IN  A      1
      <PTR>a</PTR>         <-- representing      1  IN  PTR    a
    </IP>
  </INTERFACE>

  <INTERFACE>
    <IP ADDR="2">          <-- representing      a  IN  A      2
      <PTR>a</PTR>         <-- representing      2  IN  PTR    a
    </IP>
  </INTERFACE>

</SYSTEM>

<SYSTEM>

  <DNS NAME="d"></DNS>     <-- 'd' is the only choice, so definitely system
  
  <INTERFACE>
    <IP ADDR="2"></IP>     <-- representing      d  IN  A      2
  </INTERFACE>

  <INTERFACE>
    <IP ADDR="5">          <-- representing      d  IN  A      5
      <PTR>d</PTR>         <-- representing      5  IN  PTR    d
    </IP>
  </INTERFACE>

</SYSTEM>

Again, all the correct resource records will be generated from the above XML.

These are all attempts to make sense out of abnormal data, so it's quite doubtful that the resulting <SYSTEM> elements are exactly what was originally intended, but the correct resource records should be generated from the xml of both solutions (correct meaning at least what was in the original zone files, and no additional incorrect data.) The choice of which solution to use is determined by which namespace collisions bother you least when dealing with the data structured as XML.