pavement

Talk:BIND, dynamic DNS

From FreeBSDwiki
(Difference between revisions)
Jump to: navigation, search
((added ~~~~~))
(FQDN error?: new section)
 
(3 intermediate revisions by 2 users not shown)
Line 40: Line 40:
  
 
[[User:82.182.172.103|82.182.172.103]] 06:54, 20 August 2008 (EDT)
 
[[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.)

Personal tools