ddns add-delete operation

[Jim Reid]

>>>>> "Nagendra" == Nagendra  <nagendra.shivaramaiah at wipro.com> writes:

    Nagendra> I have a query regarding DDNS-ADD operation. During the
    Nagendra> updation of 'A' type record in the nameserver, is it
    Nagendra> alright if we delete the existing record in order to
    Nagendra> avoid ambiguity. The ambiguity comes into picture in the
    Nagendra> following scenario:

    Nagendra> before addition there is only 1 entry for the host of
    Nagendra> type 'A': test.xyz.com 10.116.10.10

    Nagendra> after addition of a new A type record for the same host
    Nagendra> we have 2 entries: test.xyz.com 10.116.10.10
    Nagendra>                    test.xyz.com 10.116.10.20

    Nagendra> And if we perform a query(nslookup) for test.xyz.com, we
    Nagendra> get the old ip-adress (10.116.10.10) instead of the
    Nagendra> newly added. 

You will get both A records returned. 50% of the responses will list
"the old" address first and 50% of the answers will get "the new"
address first. nslookup is probably too stupid to cope with this and
has confused you. Sigh. Just use dig for your DNS lookups.

    Nagendra> This problem could be solved by deleting
    Nagendra> the existing 'A' type record for the hostname before
    Nagendra> adding. But how safe is it to delete a record before
    Nagendra> adding, because most of the nameservers do not give
    Nagendra> delete permission.

The DNS dynamic update protocol is based around atomic transactions.
These can consist of deletions as well as additions. They can also
include prerequisites: "delete A and add B if C doesn't exist". So
it's perfectly safe to send a dynamic update request to remove an old
A record for some name and replace it with a new one. In fact there's
even an example of this in the man page for nsupdate.

FYI, most name servers that implement DDNS do give delete permission.
DDNS without a delete capability wouldn't be all that useful. BIND9
provides fine-grained control of dynamic updates via the update-policy{}
clause. However it's not used much. Most people use allow-update{} and
let trusted clients add and remove resource records at will.

    Nagendra> Also I would like to know the very purpose of having
    Nagendra> ambiguous records in the nameserver.

Define ambigious. Name servers just do what they are told. They make
no value judgements about the data they serve and the queries they
receive. They have no way of knowing (or caring) if some resource
record is ambiguous or not -- for some definition of that term. So if
someone introduces "ambiguous" data into the DNS, presumably they've
done that for a reason. In the case of multiple A records for some
name, this could be for load balancing or providing several boxes for
www.example.com (say), perhaps on different continents. Not that these
examples of multiple A records would be ambigious.