Re: BIND9 DNSSEC algorithm rollover for inline-signed zone
Mark Andrews wrote: > Sebastian Wiesinger wrote: > > > > Thank you for explaining this for me. I was reading RFC6781, which I > > now realize is probably outdated in this regard so I was a bit > > confused. RFC 7583 (DNSSEC Key Rollover Timing) is also worth reading. > > > Once named has completed signing the zone with the new algorithm > > > and all the slaves have the fully signed zone and the caches have > > > expired any RRsets which are only signed with the old algorithm you > > > can add DS records for the new algorithm for the zone. > > > > This only applies when I change the DS record, right? I assume that I > > can add the new one instantly and remove the old one later when all > > caches have expired the old data. > > There are always timing considerations with DNSSEC. You prepublish > DS records or you have multiple KSKs. You have multiple signatures > or you have multiple ZSKs. It's all about having what you need to > validate available regardless of when the records are learnt or from > where. It is (was?) my understanding that validators are supposed to check that the DNSKEY RRSIGs include at least all of the algorithms present in the DS RRset. This is to protect against RRSIG-stripping downgrade attacks. However RFC 6840 (DNSSEC Clarifications) section 5.11 says This requirement applies to servers, not validators. Validators SHOULD accept any single valid path. They SHOULD NOT insist that all algorithms signaled in the DS RRset work, and they MUST NOT insist that all algorithms signaled in the DNSKEY RRset work. A validator MAY have a configuration option to perform a signature completeness test to support troubleshooting. which is weaker than I thought it was. I thought the algorithm rollover process is required to be: introduce new ZSK and KSK and sign the zone; wait for old records to expire; flip the DS from old to new; wait for old DS to expire; delete old ZSK and KSK and RRSIGs. A double-DS algorithm rollover will cause your zone to go bogus. This page has a pretty good description of the whys and wherefores, what Unbound's validator requires, and what its algorithm rollover bug was: https://unbound.net/documentation/info_algo.html Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Plymouth, Biscay: Northeast 4 or 5, backing southeast 5 or 6. Slight or moderate. Showers. Good. ___ 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: BIND9 DNSSEC algorithm rollover for inline-signed zone
* Tony Finch [2016-10-10 12:36]: > I thought the algorithm rollover process is required to be: introduce new > ZSK and KSK and sign the zone; wait for old records to expire; flip the DS > from old to new; wait for old DS to expire; delete old ZSK and KSK and > RRSIGs. A double-DS algorithm rollover will cause your zone to go bogus. I did the "double DS" approach, first publish new KSK/ZSK, wait for Zone TTLs, then a second DS was introduced. The zone looked like this: http://dnsviz.net/d/blau.beer/V_tTtQ/dnssec/ After the DS TTL expired I removed the old DS, so the zone now looks like this: http://dnsviz.net/d/blau.beer/V_t2Hg/dnssec/ Last step will be after DS TTL expires (again) removing the old KSK and ZSK. It seems to work. After doing this I discovered that the .tz TLD did it the same way: https://singapore52.icann.org/en/schedule/mon-tech/presentation-ksk-algorithm-09feb15-en.pdf Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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: BIND9 DNSSEC algorithm rollover for inline-signed zone
On Mon, Oct 10, 2016 at 7:51 AM, Sebastian Wiesinger wrote: > > http://dnsviz.net/d/blau.beer/V_tTtQ/dnssec/ > > After the DS TTL expired I removed the old DS, so the zone now looks > like this: > > http://dnsviz.net/d/blau.beer/V_t2Hg/dnssec/ > TBH, the prior one looks cooler than the later. -Jim P. ___ 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
forced to execute DNS64
Hello, All. Many clients queries to IPv6(IN/) domain. But IPv6 network is so far, then slow then IPv4 network. I want to forced dns64 for special domain. Example, 'm.facebook.com' IN/ address is '2a03:2880:f115:83:face:b00c:0:25de'. But I don't want to use IPv6 address. So I want to use dns64 translate address. m.facebook.com. 600 IN CNAME star-mini.c10r.facebook.com. star-mini.c10r.facebook.com. 1351 IN 2a03:2880:f115:83:face:b00c:0:25de Is it possible? Or should modify source? Thanks. ___ 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: forced to execute DNS64
DNS64 doesn't work like that. If you are having problems connecting over IPv6 contact your service provider. Facebook treats IPv6 as a production service and will deal with connectivity issues. If you want to force browsers to use IPv4 then send back RST to the connection attempts to reach the facebook servers. They should fail over to using IPv4. This should only require configuring the firewall on your router appropriately. Mark In message , LEE SUKMOON writes: > Hello, All. > > Many clients queries to IPv6(IN/) domain. > But IPv6 network is so far, then slow then IPv4 network. > > I want to forced dns64 for special domain. > > Example, 'm.facebook.com' IN/ address is '2a03:2880:f115:83:face:b00c:0:2 > 5de'. > But I don't want to use IPv6 address. So I want to use dns64 translate addres > s. > > m.facebook.com. 600 IN CNAME star-mini.c10r.facebook > .com. > star-mini.c10r.facebook.com. 1351 IN2a03:2880:f115:83:face: > b00c:0:25de > > Is it possible? Or should modify source? > Thanks. > > ___ > 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
