Find the answer to your Linux question:
Results 1 to 3 of 3
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Dynamic update of signed zone issues


    I'm currently trying to figure out how to get dynamic updates of a signed zone to work. So far I've done the following:

    dnssec-keygen -a rsasha1 -b 1024 -n zone
    dnssec-keygen -k -a rsasha1 -b 1024 -n zone
    cat*.key >>
    dnssec-signzone -t -g -o
    Added this to named.conf
    zone "" IN {
    	type master;
            file "data/";
    	update-policy {
                    grant subdomain any;
    Now when running nsupdate:

    nsupdate -d -v -k                                                                                    
    update delete A                                                                                                                                               
    update add 3600 A                                                                                 
    Everything seams fine from the nsupdate standpoint but when looking at a zone transfer the following data appears:

    Code:	3600	IN	NSEC A NSEC	3600	IN	A
    I.e. RRSIG is missing.

    If I resign the signed zone and restart the bind server it all appears right but then you kinda loose the point of dynamic DNS.

    Please advice on what I'm missing.


    Oh btw, funny thing, it works perfectly fine when removing stuff.

  2. #2


    The final step is to configure the zone to allow updates using the key. The following statements should be added to the zone options block in /etc/named.conf. The simplest configuration is to add:

    update-policy {
    grant <keyname> name <hostname> A TXT;

    zone "" {
    type master;
    file "master/";

    update-policy {
    grant name A TXT;
    Complex example with a number of hosts allowed to update only their own A+TXT records and one master key allowed to update anything:

    update-policy {
    grant name A TXT;
    grant name A TXT;
    grant name A TXT;
    grant name A TXT;
    grant subdomain ANY;
    Simple example where every key can update the A+TXT records of its matching hostname:

    update-policy {
    grant * self * A TXT;
    Note: update-policy is described further in Section of the BIND ARM.

    The allow-update statement can also be used, which allows the key to modify any data in the zone. Using more fine grained access control with update-policy is recommended.

    allow-update {
    key <keyname>;
    <keyname> is the name of the key chosen when the key was generated (See the previous step, Keys)

    Configuring the DHCP Client
    There are also two ways to configure the client:

    using the built-in dhclient updater, which you can use for TSIG keys
    using the dhclient-exit-hooks script, which you can use for TSIG or SIG(0) keys
    These two options are mutually-exclusive, i.e., you can use either the built-in dhclient updater or the dhclient-exit-hooks script, but you cannot use both at the same time.

    Using the Built-in dhclient Updater
    The built-in dhclient updater only supports TSIG keys, so if you've chosen to use SIG(0) keys, you must use the dhclient-exit-hooks script.

    The dhclient.conf file must be edited to configure the client for dynamic update using the built-in dhclient updater.

    The first step is to configure the dhclient with the fully qualified domain name of the client along with some other dynamic update options. This is accomplished by placing the following lines in the dhclient.conf file:

    send fqdn.fqdn "<client-fqdn>";
    send fqdn.encoded on;
    send fqdn.server-update off;
    <client-fqdn> is the fully qualified domain name (including the trailing dot) of the client.

    The second step is to configure the dynamic update key and zone. This is accomplished with the following lines in the dhclient.conf file:

    key <keyname> {
    algorithm HMAC-MD5;
    secret "<keydata">;

    zone <zone-fqdn> {
    key "<keyname>";
    <keyname> is the name of the key chosen when the key was generated (See previous step, Generating TSIG keys).

    <keydata> is the string after the Key: line in the generated key file (See previous step, Generating TSIG keys).

    <zone-fqdn> is the zone that will receive the dynamic update. Note that the closing } on the zone statement does not have a ; after it.

    Using the dhclient-exit-hooks Script
    dhclient allows for external events to be called via scripts placed in certain locations. See the man page on dhclient-script( for details. In this example, we use /etc/dhclient-exit-hooks to invoke nsupdate.

    dhclient does not need any specific configuration to enable use of the /etc/dhclient-exit-hooks script. If the script is present, and readable, then it will be automatically executed.

    The dhclient-exit-hooks script uses nsupdate from the BIND distribution which must be available on the client machine. nsupdate supports both TSIG and SIG(0) keys.

    If you're using TSIG keys and have decided to use the dhclient updater, then you must not use the dhclient-exit-hooks script.

    The dhclient-exit-hooks script shown below can be used for both TSIG and SIG(0) keys, the only difference is which keyfile is specified. Both the .key and .private files of the generated keyfiles must be present in the same directory on the client for nsupdate to operate correctly.


    nsupdate -v -k $KEYFILE > /dev/null << EOF
    server $SERVER
    zone $ZONE
    update delete $HOSTNAME A
    update add $HOSTNAME $TTL A $new_ip_address
    <qd.ip.of.ns> is the IP address of the nameserver. The dns name of the nameserver (with a terminal dot) may be used instead of the name, but will require a name lookup first.

    <zone-fqdn> is the zone that will receive the dynamic update.

    <fully-qualified-client-hostname> is the fully qualified domain name of the client.

    <generated-keyfile> is the filename of the .private generated keyfile including the directory (See previous section Keys).

    TTL specifies the time to live of the updated records. [ NOTE: we need to probably discuss this somewhere ]

    This script calls nsupdate, specifying -v to use TCP to send the dynamic update. The four lines "server...", zone...", update...", and update..." tell nsupdate what actions to perform on the specified zone at the specified server. The "send..." line tells nsupdate to finally send the query. See the nsupdate man page for more information.

    No changes are needed to /etc/dhclient.conf other than:

    send fqdn.fqdn "<client-fqdn>";
    send fqdn.encoded on;
    send fqdn.server-update off;
    3. Configuring Reverse Zone
    Assuming the use of TSIG to authenticate dynamic updates, three entities are involved in the updating of the "reverse map" zone corresponding to a DHCP server's IP allocations. The three entities are the DHCP server, the DHCP client, and the DNS server.

    See the previous section Keys to generate TSIG keys.

    Assuming the use of BIND's DNS implementation and ISC's dhcp (dhcpd and dhclient) implementation, three files need to be modified. The three files are /etc/named.conf (assuming default names of files), /etc/dhcpd.conf for the DHCP server, and /etc/dhclient.conf for the DHCP client.

    The steps that need to be accomplished are:

    Configure the DHCP server and DNS server to use and require authenticated dynamic update messages.
    Configure the DHCP server to update the appropriate subzone each time that a lease is let or modified.
    Configure the DHCP client to give the DHCP server a domain name to insert in a PTR RR.
    Configure the DHCP client to prohibit the DHCP server from attempting to insert an A RR for the supplied name.
    Step 1
    This step is explained in detail elsewhere. What is needed is a shared secret (again, assuming TSIG) for to secure the messages between the DHCP server and DNS server. In /etc/named.conf, the key is needed, and granted the authorization to make prescribed changes. In /etc/dhcpd.conf, the DHCP server is also given the key (using the same syntax as in the /etc/named configuration file), and is configured to use the key. "Configured" means that there is a zone statement block, with the secret specified inside.

    Configuration examples:

    In /etc/named.conf:

    key {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

    zone "" {
    type master;
    file "zones/";
    allow-update { key; };
    (Note that the use of allow-update may be too loose.)

    In /etc/dhcpd.conf:

    key {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

    zone {
    To force dhcpd to send the update to a specific server, as opposed to searching the RRset of NS RRs, you can use the

    primary <ip address>;
    sub-statement of the zone statement above.

    Step 2
    The DHCP server needs to be configured to perform updates. This is done by inserting one line in statement "ddns-update-style interim;". In /etc/dhcpd.conf:

    ddns-update-style interim;
    Step 3
    In order for the DHCP server to know how to properly form the PTR RR inserted into the reverse map zone, the DHCP server either makes up a name or uses one supplied by the client. Assuming the DHCP client wants a specific name to be used, the DHCP client must be configured to submit a name to the the server. For example, a DHCP client wanting the name "" is let the address, and will see this PTR RR appear: 3600 IN PTR
    This is done with the send fqdn.fqdn option in /etc/dhclient.conf:

    send fqdn.fqdn "";
    send fqdn.encoded on;
    The last line, "encoded on" tells the DHCP client to transmit the domain name in the DNS protocol format. This item should always be set "on."

    Step 4
    Assuming that the DHCP client machine is going to alter the "forward map" zone (the A RR), the DHCP server should not attempt to do this. There are two reasons why the DHCP server should not attempt to update the forward zone - the effort may be redundant of an effort by the DHCP client, and the DHCP server may lack the authorization that the DHCP client has to do this.

    To inform the DHCP server to not attempt the forward map update, the DHCP client specifies an option (setting). To make the DHCP client do this, in /etc/dhclient.conf:

    send fqdn.server-update off;
    In summary, the configurations shown above are summarized as this:

    In /etc/named.conf:

    key {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

    zone "" {
    type master;
    file "zones/";
    allow-update { key; };
    In /etc/dhcpd.conf:

    key {
    algorithm hmac-md5;
    secret "0huPr3nqFnxUETlrM/VxGg==";

    zone {

    ddns-update-style interim;
    In /etc/dhclient.conf:

    send fqdn.fqdn "";
    send fqdn.encoded on;
    send fqdn.server-update off;
    Setting the TTL used for A and PTR records updated by the DHCP client and server
    The DHCP client currently sets the TTL to one half of the lease duration. This means that if the client's IP address changes during that period, any cached versions of the client's A record will be wrong. The DHCP server sets the TTL of the A and PTR records to 3600 seconds, but can be configured to set it to any value. For DHCP clients, a very small value is probably appropriate - even as little as ten seconds. To set the TTL in the DHCP server, add the following to your /etc/dhcpd.conf file, where <ttl> is the desired TTL in seconds:

    ddns-ttl <ttl>;
    Setting the hostname for clients not sending the fqdn or host-name options
    To set the hostname for clients not sending the fqdn option, add something like following to your /etc/dhcpd.conf file. The actual hostname in the example below will, for ip address aaa.bbb.ccc.ddd, be dhcp-aaa.bbb.ccc.ddd. For more information on how to define your own hostname format, consult the dhcpd documentation.

    ddns-hostname = pick (option fqdn.hostname, option host-name,
    concat ("dhcp-",
    binary-to-ascii (10, 8, "-", leased-address));
    option host-name = config-option server.ddns-hostname;
    The ISC server will accept a hostname sent in the host-name option as well as the fqdn option, so the function of the code we added is simply to make up a name in the event that the client sends neither option.

    4. Troubleshooting
    In order to monitor the behaviour of a setup, proper logging should be in place.

    Configuring Logging for the DNS Server
    There are several categories that log messages fall in to. For instance, all queries fall in to the "queries" category, all notify messages will fall in to the "notify" category, and so on. We are interested in the "dnssec", the "update" and the "security" categories.

    The messages for every category are channeled into files or through syslog. The channel phrase can be used to specify which severity level should be logged, how the format of the log message should be, what extra information should be logged, where it should be logged, how many versions should be kept, and how large the zone file may grow.

    For this setup we will log all above categories in one place:

    logging {
    category dnssec { security_log; };
    category update { security_log; };
    category security { security_log; };

    channel security_log {
    file "dns-security.log" versions 5 size 20m;
    // every time the log grows over 20 Mbyte, it will
    // backup and rollover. Maximum 5 backups will be kept.
    print-time yes;
    print-category yes;
    print-severity yes;
    severity info;
    Debugging DNS updates from the DHCP server and client
    When debugging problems with DHCP server DNS updates, first make sure that the DHCP server is parsing the configuration file correctly. You can test this with "dhcpd -t". If the DHCP server prints error messages when you run it, you must fix these errors before proceeding. If you are also modifying the DNS configuration file, you may make the mistake of putting a ";" after a "}". This is allowed for the key declaration so that keys can be shared between the DHCP and DNS servers, but the DHCP server normally does not allow a ";" after a "}".

    Once you have a clean parse of the config file, you can watch what the DHCP server is doing in syslog, or you can run "dhcpd -d" to have the DHCP server run in the foreground and print errors to the controlling terminal.

    The DHCP server logs by default to the LOG_DAEMON facility. Errors are logged at LOG_ERROR, but a lot of additional information is logged at LOG_INFO or LOG_DEBUG, so if you are debugging, it's good to have a syslog file that records INFO- and DEBUG-level messages.

    Assuming that you have your DHCP client configured to send an FQDN option as described elsewhere in this document, the DHCP server should not attempt to update the client's A record. When the client gets a lease, you should see a log message like this:

    Jan 23 18:38:51 dhcpd dhcpd: added reverse map from to
    If, instead, you see a message like this, it means that the client is not sending a fully-qualified domain name:

    Jan 23 18:38:51 dhcpd dhcpd: unable to add reverse map from to
    This can be either because it is not sending an FQDN option at all, or because it is sending an unqualified domain name in the FQDN option. It is possible to see this same problem even if your client is sending an FQDN option that contains more than one label. For example, you might see:

    Jan 23 16:20:39 dhcpd dhcpd: Unable to add forward map from
    laptop.yfd.example.yfd.example to timed out
    This means that the client has almost been configured with a fully-qualified domain name, except that the root label was left off. On the ISC DHCP client, you need to do this:

    send fqdn.fqdn "laptop.yfd.example.";
    not this:

    send fqdn.fqdn "laptop.yfd.example";
    Notice the trailing '.' in the first example. If the client doesn't send a fully-qualified domain name, the DHCP server assumes that the name is to be added in a forward zone that has been configured on the server. You will also see this behavior if the client has not been configured to tell the server that it will update its own A record. You must have this line in your dhclient.conf:

    send fqdn.server-updates false;
    If you see a message like this, it means either that your DHCP server isn' t using the right key to update the record, or that it is not using any key to update the record, or that the primary DNS server for the zone is not reachable. Make sure you have a zone statement, and that you used the same name for the key on both the DHCP and DNS servers:

    Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43. 30 IN PTR laptop.yfd.example: timed out.
    If you see this message, your key isn't a valid key to use to update the zone:

    Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43. 30 IN PTR laptop.yfd.example: invalid TSIG key.
    If you see this, your clocks are out of sync. Make sure you use "date -u" when comparing clock times. Clocks must be within five minutes of each other:

    Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43. 30 IN PTR laptop.yfd.example: clock skew too great.
    This message means that the zone statement in your configuration file doesn't refer to an actual zone in the DNS. It is possible to have a subdomain that is not a zone. In order for a domain to be a zone, it must have an SOA record. So if you get this message, find the most specific SOA record above the name you are updating and write a zone declaration for the name to which that SOA record is attached:

    Jan 23 16:29:47 dhcpd dhcpd: delete IN PTR add 43. 30 IN PTR laptop.yfd.example: not a zone.
    The same logging configuration described for the server applies to the client. The error messages described above also have the same meanings on the client.

    5. Limitations and Possible Complications
    The documentation for the involved programs and protocols could be clearer and definitely need more and better examples. This has been reported and will hopefully be improved in the future.

    Syntactic differences
    There are unfortunate syntactic differences between dhclient.conf, dhcpd.conf, and /etc/named.conf. In some places a certain item is expected to be surronded by quotes ("), in other places not. Sometimes a command is terminated with semicolon (, in other places the same command is not, etc. This is very confusing, and one has to read the documentation carefully.

    The clocks in the participating computers must be in sync, especially for updates for updates performed with TSIG. Use of NTP is strongly recommended.

    Serial numbers
    Since the SOA serial number is incremented for every update of the zone file, one can no longer depend on the correctness of numeric structures (such as the common YYYYMMDDnn formula) of serial numbers in zones subject to dynamic updates. Beware that if you lower the serial number in an existing zone, you have to take manual steps to re-synchronize all slave servers for the zone.

    The DNS TTL (time to live) property mixes poorly with dynamic updates and DHCP. There is no guarantee that the TTL will match the remaining DHCP lease time for the client at any given moment. This remains to be a discussion topic.

    Deleting the updates in the forward tree
    After one leaves the temporary network, the forward tree must be updated to remove the temporary IP address issued by the DHCP server. Many options were suggested, but all were rejected because of some issue or another.

    Do nothing - rejected because the IP address may be re-assigned before the DHCPclient can change it again.
    Delayed deletion - the client sends a pre-signed "delete" dynamic update message to the DHCP server to send after a lease expiring. Defeated becuase opens up a DoS attack (attacker issues replay attack after the lease renew, but before the TSIG fudge value expires).
    Forward server watchdog process that listens for remote host to leave the net - messy to implement, and may not work if remote connection is not consistant.
    Have the forward DNS server "lease" the change - also messy and may result in errors causing service denials.
    Separate dynamic zones
    It seems unlikely that dynamic update, regardless of its security, will be enabled for all zones. Among the reasons for this is the different traceability characteristics of a zone with "important servers" and a zone with "mobile laptops". In the server zone it is crucial to be able to keep track of who did exactly what change when and why, and typically the (static) zone file is under some sort of revision control that interacts extremely poorly with a dynamically updated zone.

    But at the same time it seems unlikely that people using dynamically updated DNS entries for their machines will be satisfied with an longer (therefore percieved as "inferior") domainname like ""

    The best suggestion we have to ameliorate this situation is to go the CNAME way. I.e.: IN CNAME
    However, if and when doing that, it is probably desirable to have the reverse mapping point at the "exposed name, rather than the CNAME. I.e.: IN PTR
    DNS Server Side
    BIND only
    The only DNS server available to the workshop participants that was able to deal with dynamic updates of secure zones at the time was BIND. Thus, we only give you instructions for platforms that are supported by BIND for the DNS serers.

    Update policy
    The zone subject to dynamic updates needs an update policy. Care should be exercised to not devise a too liberal update policy. Especially the zone apex records (SOA, NS, ...) need to be protected from updates by malicious/clueless clients.

    Manual updates and journal files
    When dynamic update is enabled for a zone, the zone can no longer be manually edited as normal. Attempting to do so may work in some cases, but will usually result in a name server error.

    The DNS server keeps a journal file of incoming updates. The file is not automatically syncronized with the zone file, but can be forced with the "rndc stop" command. Extreme care has to be exercised when manually updating a zone subject to dynamic updates.

    When using BIND 9.2, the following must be done to edit a master file of a zone maintained by dynamic update. Note that this stops named until the process is complete.

    rndc stop
    remove the journal file (.jnl)
    edit the zone
    start named
    When using a recent BIND 9.3 snapshot (that is, newer than bind-9.3.0s20020122) , the following can be used instead, which does not require that named be stopped:

    rndc freeze zone
    edit the zone
    rndc unfreeze zone
    DHCP Client Side
    The DHCP client in MacOS does not know how to do dynamic updates, so it could not be used in the tests.

    The DHCP client in Windows does do updates, but needs GSS-TSIG to have full functionality, so it could not be used either in the tests.

    Updates seem to work with modern DHCP clients running on Unix or Linux.

    First cycle bug
    Several BSD platforms reported that when the dhclient was tasked with sending updates, the update would not reach the DNS server when the IP address was initially handed out, but when it was refreshed (half a lease time later) the update came and was processed orderly. This was found to be a race condition in the dhclient, and will be fixed in coming releases.

    dhclient uses a DHCP-ID to indicate that a DNS record has been updated by a certain client. The DHCP-ID is either provided by the client as a configured value, or a hash value automatically computed over a combination of the FQDN of the host and its MAC address. Currently the DHCP-ID is stored in the DNS (by dhclient) as a TXT record (in lack of a proper DNS record). dhclient will only update the record if it either doesn't exist at all, or if the corresponding DHCP-ID matches. Otherwise it's left as it is. Therefore, if a DNS file contains a static record for a hostname, that you suddenly want to allow dynamic updates to, the record must first be removed manually. If there is another TXT record with the same owner name, the update will not take place.

    No turning off forward updates
    The DHCP server is told by the dhclient whether the server is expected to update the forward zone or not. The configuration is such that either the server is tasked to do this, or the client assumes that it should to it itself. There is no way to configure the client to neither tell the server to do it, nor perform the update itself. This is problematic if you want to do the update from a script outside the dhclient.

    Multiple forward zones
    dhclient does not yet deal with multiple forward zones, i.e., a laptop can not automatically update the two zones, and

    Updating Signed Zones
    DNSSEC model changing
    This document does not cover how to make your zone secure. Please be aware that the DNSSEC model is undergoing change, and the workshop was based on the available software that handles the RFC 2535 model. It is expected that this model will change when/if the "Delegation Signer (DS)" record is introduced. (See "draft-ietf-dnsext-delegation-signer-05.txt", work in progress). Since DS is not handled by current software, it could not be tested.

    Deleting the last record
    BIND 9.2.0 has a bug where if you try to delete the last data record (apart from the zone SOA and NS records) from a zone, it will fail to perform the update. The bug may show its ugly face under other circumstances too. The bug has been reported but not yet fixed.

    Signing key on-line
    If the server is to be able to update records in a signed zone, it must be able to sign new records added to the zone. Thus the private half of the zone key must be stored on line, at the name server's disposal, typically as a readable file in the directory specified in the "directory ".....";" statement in the /etc/named.conf file. This might be considered bad security practice.

    TSIG vs. SIG(0)
    The BIND 9.2.0 way of securing the update transaction is through TSIG. TSIG uses symmetric keys, which means, in a sense, a system with a higher built-in risk than one with asymmetric keys. If one side is compromised, the other one falls at the same time. The alternative method with asymmetric keys (usually referred to as SIG(0)) is not easily supported in BIND 9.2.0, but given the higher risk with symmetric keys, SIG(0) is the preferred method. There are patches for BIND 9.2.0 to support this, and it will hopefully be supported in future releases.

    TTLs and signature lifetimes
    As mentioned, TTLs mix poorly with dynamic updates, and even more so with DNSSEC signatures. Signature lifetimes can be specified for all records in a zone, but there is currently no way to specify them with better precision than days. This should probably be mended in the future, but it has complicated consequences for caching and signature validation, and it remains an open question how you should choose the signature lifetimes and whether all records should have the same lifetime.

    It should also be noted that the server will not automatically re-sign records for which the signature has expired. The consequences of this are not fully penetrated.

    Signing updates with multiple keys
    If multiple zone keys are present in the zone, but not in the BIND working directory, a SERVFAIL error is returned for the update. This bug has been fixed and the fix will be part of future releases. The solution will be that the server will generate SIG records using any zone keys found in the directory.

    Updating the zone apex - don't!
    You must not update the KEY record at zone apex, since that will immediately invalidate entire zone, due to the fact that the KEY record set has changed, and the parent SIG is thereby no longer valid.

    Key roll-over
    Doing key roll-over is extremely complicated, especially if one wants to do it from a remote site. The following text demonstrates the issues involved wrt key-rollover in a dynamic updated zone. The steps described below is a rough generalisation on the actual steps involved.

    This is the basic idea:

    There are 3 states,

    "before" production state
    "rollover" state
    "after" production state
    The purpose of this excersize is to minimize the "rollover-state" time, since production state is critical.

    while in state 1):

    1.1 Generate new key
    1.2 Generate the key-set
    1.3 Have the key-set signed by the parent
    1.4 Change the configuration, so updates are not allowed
    The following will transfer the nameserver from state 1 to state 2. A possible feature request may be (and is already issued to have the two steps below in one (ie. rndc flush & dissallow update) (see issues section)

    1.5 Stop the nameserver, so the journal-file gets flushed into the zone.
    2.1 Start the nameserver. Now updates are not allowed.
    while in state 2:

    2.2 Add keyset to zone.
    2.3 Resign zone.
    2.4 Change configuration back to allow update.
    The following command puts the status in state 3)

    3.1 rndc reload
    The above scenario demonstrates the clash between dynamicly updating the zone and manually updating the zone (one needs to re-sign the zone with the new key).

    As shown above, during the re-sign of the zone, it needs to be physically on disk, and therefore new dynamic updates need to stop (temporarily) and current (pending) updates needs to be flushed to the zone on disk.

    If there is a strong requirement for dynamic updates, stopping the nameserver from receiving dynamic updates poses a problem.

    Several solutions to this problem came to mind:

    Dynamically resigning a zone (infinite ugliness!)
    After the new private key is put on the nameserver, one can traverse the zone (through NXT records) and dynamically update all records.
    Somehow accept and que pending updates (significant ugliness).
    This introduces another problem. If the "rollover state" exceeds the time a dynamically updated record exists (i.e. add-delete during this time) the nameserver does redundant work, and meanwhile the client is not able to have its desired records published.
    Somehow accept and propagate updates during the zone-signing session (moderate ugliness)
    This means the journal file will already have the signatures of the new key, the file-on-disk is signed offline, and after a flush, the journal file will be included in the zone-file-on-disk. Eventhough the zone file is manually changed, there are no records deleted, no new names added, and only records (NXT SIG) with the same name changed. Since it is not allowed to manually update (delete) NXT and SIG records, there seems to be no clash. This makes it ofcourse impossible to perform an ixfr.

  3. #3
    If you read my post you can see that the grant statement is added. When using SIG(0) keys you're not including your private key into named.conf, nsupdate communicates directly with the zone authentication against the public key DNSKEY which is present in the zone.

    Issue remains, RRSIG isn't set when updating with nsupdate.

  4. $spacer_open

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts