-
-
Notifications
You must be signed in to change notification settings - Fork 72
Description
When using NetDNS2 v2.0.3, unable to update the exchange of an MX record if the domain (rightmost two labels) of the new exchange is the same as the old exchange. Nameserver returns format error. Same update works fine if the new exchange is a different domain.
Sample (MX record of $oldmx exists in nameserver):
$oldmx = MX::fromString("somedomain.com 86400 IN MX 10 mx01.b.com");
$newmx = MX::fromString("somedomain.com 86400 IN MX 10 mx02.b.com");
$u = new Updater("somedomain.com");
$u->nameservers = array("192.168.1.1");
$u->delete($oldmx);
$u->add($newmx);
$u->update($ans);
Other type updates also fail with slightly different behavior. E.g. - if updating TTL or preference but exchange is same, results in removing exchange on nameserver (replaces with ".").
If I change the Domain type to Data::DATA_TYPE_CANON in rrFromString() and rrSet() functions of MX.php, updates work as expected. Wondering if wire format wrong for exchange field of MX record when set to DATA_TYPE_RFC_1035.
A similar issue exists when updating an NS record with a a new nsdname. v2.0.3 works fine if new nsdname is in a different domain. But if new nsdname is in same domain, the result of the DDNS update is an incorrect value where it looks to prepend the left most portion of nsdname to the old name instead of replacing it. Also wondering if wrong wire format for the nsdname field as changing Domain type to Data::DATA_TYPE_CANON in rrFromString() and rrSet() functions of NS.php also seem to fix issue.
Sample (NS record of $oldns exists in nameserver):
$oldns = NS::fromString("somedomain.com 86400 IN NS ns01.b.com");
$newns = NS::fromString("somedomain.com 86400 IN NS ns02.b.com");
$u = new Updater("somedomain.com");
$u->nameservers = array("192.168.1.1");
$u->delete($oldns);
$u->add($newns);
$u->update($ans);
Results in nsdname of "ns02.ns01.b.com" instead of "ns02.b.com". Also has odd behavior when changing TTL where nsdname is removed on nameserver.
I've not tested but guessing same issue may exist with PTR.php as it also uses DATA_TYPE_RFC1035 for ptrdname when creating from rrFromString().