Re: SOA record not signed with new key at key-rollover

[Mark Andrews]

In message <5788c969.6070...@enbewe.de>, Nis Wechselberg writes:
> Hi,
> 
> I am curently testing a dnssec setup with the new dnssec-keymgr tool. I
> created a test zone with very fast key rollover setings and very short
> TTLs. (Configs below)
> 
> The automated creation of keys seems to work fine but bind behaves other
> than I would have expected.
> 
> - Initial deployment looks fine with the current ZSK published and in use.
> (http://dnsviz.net/d/testmichhartundwild.de/V4ep6A/dnssec/)

ZSK = 36141
 
> - At prepublication time the next key is published but not yet used (as
> expected.
> (http://dnsviz.net/d/testmichhartundwild.de/V4fV_A/dnssec/)

New ZSK is 10173

> - After rollover time the new key is used to sign the zone EXCEPT the
> SOA record. This one is still signed by the old key.
> (http://dnsviz.net/d/testmichhartundwild.de/V4fyNQ/dnssec/)

No.  The new ZSK signs the SOA record.  The old signatures still exist
on the other records as the only RRset that changes is the SOA.
 
> - When post-publication of the old key expires it is removed and the new
> key is used for all records.
> (http://dnsviz.net/d/testmichhartundwild.de/V4gSGg/dnssec/)
> 
> 
> I am confused becaus of the special treatment of the SOA record. I would
> expect a complete switch to the new key. At the moment, cached responses
> of the SOA record could not be verified in the timeframe between
> deletion of the old key and the next TTL.
> 
> Am I missing something?
> 
> Regards,
> Nis
> 
> 
> 
> 
> dnssec-keymgr policy:
> 
> zone testmichhartundwild.de {
>   algorithm RSASHA256;
>   directory "/etc/bind/zones/keys";
>   coverage 2d;
>   keyttl 600;
>   roll-period zsk 8h;
>   post-publish zsk 2h;
>   pre-publish zsk 2h;
> };
> 
> 
> bind zone config:
> 
> zone "testmichhartundwild.de" IN {
>   type master;
> 
>   file "de/testmichhartundwild.de/zone.db";
> 
>   // Allow zone transfers to trusted servers
>   allow-transfer {
> myServers;
> localhost;
>   };
> 
>   // Allow updates with shared key
>   update-policy {
> grant morpheus-trinity. zonesub any;
>   };
>   serial-update-method unixtime;
> 
>   // Activate dnssec for this domain
>   key-directory "keys";
>   auto-dnssec maintain;
> };
> 
> 
> ___
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Resolving issue on specific domain

[Matus UHLAR - fantomas]

On 15.07.16 14:05, Daniel Dawalibi wrote:

Dig domainname -> Server failed



On Jul 15, 2016, at 8:48 AM, Matus UHLAR - fantomas  wrote:

please show us output of it.
when 127.0.0.1 is first in /etc/resolv.conf, dig should contact localhost
first, and the result should be the same as dig @localhost domainname.


On 15.07.16 09:56, Chris Buxton wrote:

You should not rely on the order of entries in resolv.conf. Servers will
not always be queried in the listed order.  This is
implementation-specific.


got more info? looks liker some implementations don't support
preferred/fallback mechanism.


If you have two servers that will answer differently to the same query,
then you shouldn't have those two servers in resolv.conf.  Aim for a
consistent (and consistently useful) result.


yes, why to have fallback when you may not have it...

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
___
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