Talk:BIND, dynamic DNS
(len) |
(→FQDN error?: new section) |
||
(7 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | == variable set wrong? == | ||
in set-ddns.pl: | in set-ddns.pl: | ||
Line 8: | Line 9: | ||
par non, complimenteré? | par non, complimenteré? | ||
+ | |||
+ | --[[User:82.182.172.103]] 17:41, 19 August 2008 (EDT) | ||
+ | |||
+ | == nope. see '''man nsupdate''' == | ||
+ | |||
+ | nsupdate uses the -y or -k option (with an HMAC-MD5 key) to provide the | ||
+ | shared secret needed to generate a TSIG record for authenticating | ||
+ | Dynamic DNS update requests. These options are mutually exclusive. With | ||
+ | the -k option, nsupdate reads the shared secret from the file keyfile, | ||
+ | whose name is of the form '''K{name}.+157.+{random}.private'''. | ||
+ | |||
+ | Kinda confusing, I know, but I'm not the one who made the confusion. (Note how the manpage itself refers to the file as "keyfile" in the argument examples; I'm just following the existing conventions by naming my own variable $KEYFILE.) | ||
+ | |||
+ | Reading on in the manpage: | ||
+ | |||
+ | For historical reasons, the file K{name}.+157.+{random}.key must also be | ||
+ | present. | ||
+ | |||
+ | So, there ya have it. =) | ||
+ | |||
+ | --[[User:Jimbo|Jimbo]] 22:59, 19 August 2008 (EDT) | ||
+ | |||
+ | == oh == | ||
+ | |||
+ | yes, there I have it (smiley). | ||
+ | |||
+ | however it seems that it does not matter which of the two files I feed to nsupdate -- it works in either case. indeed, ''nsupdate -k Kclient.server.net.+157+15661'' (without the last part, notice) is valid too. well, at least this is true on the debian system I am testing this on. | ||
+ | |||
+ | weird or just convenient? | ||
+ | |||
+ | [[User:82.182.172.103|82.182.172.103]] 06:54, 20 August 2008 (EDT) | ||
+ | |||
+ | == a little bit of both == | ||
+ | |||
+ | The secret (ha) is that the keyfile HAS to be in the very stilted form mentioned, with both the .private and the .key present in that directory. I discovered the hard way that if you veer from that formula one tiny millimeter, nsupdate breaks with no or extremely unhelpful messages. You also HAVE to be IN the directory in question when you issue the command - specifying the full path to the keyfile isn't enough, you MUST be actually IN that directory. | ||
+ | |||
+ | I suspect the codebase for nsupdate could use some lovin'. | ||
+ | |||
+ | --[[User:Jimbo|Jimbo]] 09:28, 20 August 2008 (EDT) | ||
+ | |||
+ | == FQDN error? == | ||
+ | |||
+ | Shouldnt the SOA record in the example zone file be | ||
+ | |||
+ | $ORIGIN . | ||
+ | $TTL 10 ; 10 seconds | ||
+ | client.server.net. IN SOA ...... | ||
+ | ... | ||
+ | ... | ||
+ | $ORIGIN client.server.net | ||
+ | |||
+ | instead of | ||
+ | |||
+ | $ORIGIN . | ||
+ | $TTL 10 ; 10 seconds | ||
+ | client.server.net IN SOA ...... | ||
+ | ... | ||
+ | ... | ||
+ | $ORIGIN client.server.net | ||
+ | |||
+ | ? (Note the trailing dot in the SOA line.) |
Latest revision as of 14:39, 11 May 2013
Contents |
[edit] variable set wrong?
in set-ddns.pl:
$KEYFILE should probably point to the key file, not the private file.
$KEYFILE = 'Kclient.server.net.+157+15661.private'; should read $KEYFILE = 'Kclient.server.net.+157+15661.key';
par non, complimenteré?
--User:82.182.172.103 17:41, 19 August 2008 (EDT)
[edit] nope. see man nsupdate
nsupdate uses the -y or -k option (with an HMAC-MD5 key) to provide the shared secret needed to generate a TSIG record for authenticating Dynamic DNS update requests. These options are mutually exclusive. With the -k option, nsupdate reads the shared secret from the file keyfile, whose name is of the form K{name}.+157.+{random}.private.
Kinda confusing, I know, but I'm not the one who made the confusion. (Note how the manpage itself refers to the file as "keyfile" in the argument examples; I'm just following the existing conventions by naming my own variable $KEYFILE.)
Reading on in the manpage:
For historical reasons, the file K{name}.+157.+{random}.key must also be present.
So, there ya have it. =)
--Jimbo 22:59, 19 August 2008 (EDT)
[edit] oh
yes, there I have it (smiley).
however it seems that it does not matter which of the two files I feed to nsupdate -- it works in either case. indeed, nsupdate -k Kclient.server.net.+157+15661 (without the last part, notice) is valid too. well, at least this is true on the debian system I am testing this on.
weird or just convenient?
82.182.172.103 06:54, 20 August 2008 (EDT)
[edit] a little bit of both
The secret (ha) is that the keyfile HAS to be in the very stilted form mentioned, with both the .private and the .key present in that directory. I discovered the hard way that if you veer from that formula one tiny millimeter, nsupdate breaks with no or extremely unhelpful messages. You also HAVE to be IN the directory in question when you issue the command - specifying the full path to the keyfile isn't enough, you MUST be actually IN that directory.
I suspect the codebase for nsupdate could use some lovin'.
--Jimbo 09:28, 20 August 2008 (EDT)
[edit] FQDN error?
Shouldnt the SOA record in the example zone file be
$ORIGIN . $TTL 10 ; 10 seconds client.server.net. IN SOA ...... ... ... $ORIGIN client.server.net
instead of
$ORIGIN . $TTL 10 ; 10 seconds client.server.net IN SOA ...... ... ... $ORIGIN client.server.net
? (Note the trailing dot in the SOA line.)