RFC 2136 updating

The other form of DDNS supported by pfSense is RFC 2136 updating. This form of DDNS is more like traditional DNS, and is the standardized method of dynamically updating DNS records. It offers the following advantages over the DDNS method described in the previous section:

  • More secure: RFC 2136 uses Transaction Signature (TSIG), which uses shared secret keys and one-way hashing in order to provide a cryptographically secure means of authenticating DNS updates.
  • Good for enterprises: RFC 2136 is supported by many enterprise-level applications, including such directory services as LDAP and Windows' Active Directory. It is also supported by BIND servers and Windows Server DNS servers.
  • Standardized: Whereas the DDNS services described in the last section often must be configured in different ways depending on which provider you use, all systems that utilize RFC 2136 are following the same standard; thus, configuration is somewhat easier.

There are also some disadvantages to using RFC 2136. Wildcarding is not supported by this standard. Also, there does not seem to be a means of forcing updates, so it may take somewhat longer for updates to take effect.

  1. You can get started with RFC 2136 configuration by navigating to Services | Dynamic DNS and clicking on the RFC 2136 tab. You will see an RFC 2136 client table which is similar to the table on the Dynamic DNS tab.
  2. Click on the green +Add button down and to the right of the table to add a client.
  3. While the DDNS client configuration page had a Disable checkbox, the RFC client configuration page starts off with an Enable checkbox that you must check for this client to be enabled.
  4. The next option is the Interface drop-down box. The selected interface should almost always be WAN.
  5. Next is Hostname, in which you must enter the fully qualified domain name of the host to be updated.
  6. After that there is TTL, which controls how long the DNS record to be updated should be cached by caching name servers. You will likely want to make this a relatively small number (smaller than the traditional 86,400 seconds), as this parameter controls how long a DNS server could be showing the old value after an update.
  7. The next value is Key Name, which is whatever name you gave the key when you created it on your DNS server. Usually it is identical to the fully qualified domain name. The Key Type value must match the type of the key specified in Key Name; usually you can specify Host as the option.
Version 2.4.3 has removed the Key Type option and has added a Key algorithm drop-down box in which you can select the key encryption algorithm (HMAC-SHA512 is the most secure of the options). The Key field should be the secret key generated when you created the specified key.
  1. In the Server field, you must specify the IP address of the DNS server the client will be updating.
  2. The next option is the Use TCP instead of UDP checkbox. DNS uses TCP for zone transfers and for queries larger than 512 bytes and UDP for name queries, so in most cases, you should leave this unchecked. If you are updating a zone record, however, you will want to check this box. You should probably check this box, especially if you are using DNSSEC and/or IPv6.
  3. The Use public IP checkbox will attempt to use the public IP address to fetch if the DNS server's IP address is private.
  1. The Record Type option allows you to specify whether the client should update A records (for IPv4), AAAA records (for IPv6), or both.
  2. Finally, in Description you can enter a brief (non-parsed) description of this entry. Click on the Save button to save the entry, and you should be returned to the client table with the new entry in the table.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset