Re: "if exists host-name" for IPv6 DDNS?

[Joachim Tingvold]

On Sep 23, 2011, at 09:21 GMT+02:00, Matthew Seaman wrote:
>> Or replace :: with _, 
> 
> '_' is an illegal character in hostnames in the DNS…

Oh, that slipped right passed me. I should know that "_" isn't valid.

Thanks for the heads up, and for pointing out my fourth mistake in the same 
e-mail (-:

-- 
Joachim
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "if exists host-name" for IPv6 DDNS?

[Joachim Tingvold]

On Sep 23, 2011, at 01:32 GMT+02:00, David Miller wrote:
>>> "2001:20a0:4000:300::123" would become "2001-20a0-4000-300-69".
>> The result should of course be "2001-20a0-4000-300-123" (-:
>> 
>> Sorry for the confusion.
> ...or should the result be 2001-20a0-4000-0300----0123 ?

Ideally "2001-20a0-4000-300-123", but "2001-20a0-4000-0300----0123" 
would work too. Or replace :: with _, which would yield 
"2001-20a0-4000-300_123".

In any case; I realize that this should've gone to dhcp-users, and not 
bind-users. This clearly isn't my day (-:

-- 
Joachim
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: "if exists host-name" for IPv6 DDNS?

[Joachim Tingvold]

On Sep 23, 2011, at 00:09 GMT+02:00, Joachim Tingvold wrote:
> "2001:20a0:4000:300::123" would become "2001-20a0-4000-300-69".

The result should of course be "2001-20a0-4000-300-123" (-:

Sorry for the confusion.

-- 
Joachim
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

"if exists host-name" for IPv6 DDNS?

[Joachim Tingvold]

Hi,

Is there any equivialent to the following syntax, that works with IPv6 DDNS?

   if exists host-name {
  ddns-hostname = lcase(option host-name);
   } else {
  ddns-hostname = binary-to-ascii(10, 8, "-", leased-address);
   }

If the hostname the client provided already exists, it should use the 
IPv6-address to make the hostname.

"2001:20a0:4000:300::123" would become "2001-20a0-4000-300-69".

-- 
Joachim
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: «tsig verify failure» only on some zones

[Joachim Tingvold]

On Wed, Aug 18, 2010, at 00:42:40AM GMT+02:00, Hauke Lampe wrote:

What TSIG algorithms do you use and how long are the keys?


HMAC-MD5, 128 bit. The keys are 24 chars long. I'll try to test with  
another algorithm, however I find it quite strange; if it works for  
some zones, why doesn't it work for the others?


It could be that you hit an interoperability bug in BIND that was  
fixed in 9.7.0, although it doesn't fit the symptoms exactly:


I see. No, it doesn't seem like the same symptoms. I could of course  
try to downgrade NS3, or upgrade the two other, but I'd consider that  
as a last-resort solution.


--
Joachim
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

«tsig verify failure» only on some zones

[Joachim Tingvold]

Hi,

I've been trying to wrap my head around this for a while now, so I  
thought I'd ask around here.


For a while, I've had two nameservers, one master (let's call this  
NS1), one slave (let's call this NS2) -- which has been working  
flawlessly. They've both run BIND 9.6-ESV-R1 on Debian Lenny, and has  
static, public IP-addresses.


I've tried to get a third nameserver (let's call this NS3) up and  
running. This one runs BIND 9.7.0-P1 on Debian Squeeze, and sits  
behind NAT (a Cisco-router, FWIW). Proper measures have been taken  
(ie; proper ports have been opened, «no-payload» has been applied,  
debug shows no packets being dropped, so I think I've ruled out this  
to be a NAT-issue -- I could be wrong, though).


During initial startup of NS3, most zones gets «tsig verify failure»,  
but some zones are successfully transferred. All zones uses the same  
transfer-key.


I pulled some logs, from both NS1 and NS3, showing what's happening on  
both sides; . For  
clarification; 80.0.0.1 is the public IP of NS3, and 90.0.0.1 is the  
public IP of NS1.


I notice that «request failed: end of file» shows up sometimes; this  
also shows up in the logs on NS2, but transfers all the zones without  
issues. NS2 has an identical config to NS3 (except other forwarders,  
etc), so I've assumed this isn't what's causing the «tsig verify  
failure». Maybe I'm wrong?


I could also mention that all three nameservers are chrooted, but  
they've all been created with the same script, so the setups are  
identical.


The timestamps from the logs differs by about ~40 seconds -- is this  
too much a variation?


Could this be an issue with different BIND-versions, or are there  
other matters that could cause this?


--
Joachim
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users