Manuel Pear

Niveau superieur
Sommaire

Examples -- DNS Updates

Examples -- DNS Updates -- RFC 2136 DNS Updates

RFC 2136 DNS Updates

By constructing a specially formatted DNS packet and sending it to a nameserver, a dynamic DNS update can be performed very easily. RFC 2136 defines some variations of a DNS packet that are used by Net_DNS to request an update. The nameserver must first be configured to accept DNS updates, a key must be established between the client and server, and most importantly, the PHP mhash extension must be included for processing the MD5 digest of the key.

The format of the DNS packet is very specific and requires in-depth knowledge of how DNS updates work. Net_DNS currently does not support any abstraction of these specially formatted packets. Packets must currently be crafted and sent manually. The full formatting of update packets can be found in RFC 2136.

For a complete listing of all of the fields that are available for DNS updates, please review RFC2136 (http://www.ietf.org/rfc/rfc2136.txt). The following examples show the simplest forms of a DNS update.

Exemple 54-1. Sending a dynamic DNS update packet to a nameserver

  1. <?php
  2. require_once 'Net/DNS.php';  
  3.  
  4. $resolver = new Net_DNS_Resolver();  
  5.  
  6. // We should only send the request to the master server
  7. // accepting DNS updates for the zone.
  8. $resolver->nameservers = array('192.168.0.254');  
  9.  
  10. // We must manually construct the DNS packet for a DNS update
  11. // First we must instantiate the packet object
  12. $packet = new Net_DNS_Packet();  
  13.  
  14. // Create the header for the update packet. Most of the defaults are
  15. // acceptable, but we must set the header OPCODE to "UPDATE"
  16. $packet->header = new Net_DNS_Header();  
  17. $packet->header->id = $resolver->nextid();  
  18. $packet->header->qr = 0;  
  19. $packet->header->opcode = "UPDATE";  
  20.  
  21. // As specified in RFC2136, the question section becomes the "ZONE" section.
  22. // This specifies the zone for which we are requesting a change. This
  23. // reflects the zone configuration as specified in the nameserver
  24. // configuration.
  25. $packet->question[0] = new Net_DNS_Question('example.com', "SOA", "IN");  
  26.  
  27. // The "ANSWER" section of the packet becomes the "PREREQUISITE" section of
  28. // the packet. Section 2.4 of RFC2136 defines the possible values for this
  29. // section. As show below, without any prerequisites the nameserver will
  30. // attempt to perform the update unconditionally.
  31. $packet->answer = array();  
  32.  
  33. // The AUTHORITY section becomes the "UPDATE" section of the DNS packet. The
  34. // UPDATE section is a collection of resource record updates that should be
  35. // modified in one form or another. RRs can be deleted or added based on the
  36. // values passed in the RR object. These values are specified in RFC2136 but
  37. // are summarized here:
  38. //
  39. // Adding an RR
  40. // A complete RR object with a non-zero TTL is considered an addition.
  41. //
  42. // Deleting an RR
  43. // A complete RR object with a zero TTL is considered an deletion. An RR that
  44. // matches (exactly) with all values except for the TTL will be removed.
  45. //
  46. // Deleting an RRset
  47. // A complete RR object with a zero TTL and a type of ANY is considered a
  48. // deletion of all RRs with the specified name and type. An RR that matches
  49. // (exactly) with all values except for the TTL and the TYPE will be removed.
  50. //
  51. // Deleting all RRsets for a name
  52. // A complete RR object with a zero TTL, a type of ANY, and a class of ANY is
  53. // considered a deletion of all RRs with the specified name. Any RR that
  54. // matches the name section of the query will be removed.
  55. //
  56. // The following specification will delete the RR that has a name of
  57. // "example.com", class of "IN", type of "A", and an address of
  58. // "192.0.34.166".
  59. $rrDelete =& Net_DNS_RR::factory("example.com. 0 IN A 192.0.34.166");  
  60. //
  61. // The following specification will add an RR that has a name of example.com,
  62. // a TTL of 1 hour, a class of "IN", type of "A", and an address of
  63. // "192.0.34.155"). Note that the only difference between this RR and the
  64. // previous RR is the value of the TTL.
  65. $rrAdd =& Net_DNS_RR::factory("example.com. 3600 IN A 192.0.34.166");  
  66. //
  67. // The RR modifications are added to the authority (UPDATE) section of the DNS
  68. // packet.
  69. $packet->authority[0] = $rrDelete;  
  70. $packet->authority[1] = $rrAdd;  
  71. //
  72. // The signature must be present in any packet sent to a nameserver that
  73. // requires authentication. The TSIG RR is added to the additional section of
  74. // the DNS packet.
  75. $tsig =& Net_DNS_RR::factory("keyname.as.specified.in.server. TSIG ThisIsMyKey");  
  76. $packet->additional = array($tsig);  
  77. // Net_DNS does not automatically calculate the number of records stored in
  78. // each section. This calculation must be done manually.
  79. $packet->header->qdcount = count($packet->question);  
  80. $packet->header->ancount = count($packet->answer);  
  81. $packet->header->nscount = count($packet->authority);  
  82. $packet->header->arcount = count($packet->additional);  
  83. //
  84. // After creating your packet, you must send it to the name server for
  85. // processing. DNS updates must use the send_tcp() method:
  86. $response = $resolver->send_tcp($packet, $packet->data());  
  87. //
  88. // The response from the server will vary. If the update was successfuly, the
  89. // server will have a response code of "NOERROR". Any other error types will
  90. // be reported in the response packet's header "rcode" variable.
  91. if ($response->header->rcode != "NOERROR") {  
  92. return($response->header->rcode);  
  93. }  
  94.  
  95.  
  96. ?> 
Niveau superieur
Sommaire

Remonter Remonter
L'éditeur javascript - CSS - Gentoo - Tutoriaux PHP - Tutoriels PHP - Bretagne - php - Moto - Kit graphique