- Ns.se - lists.iis.se

Sista påminnelsen: Root Zone KSK Rollover on October 11

by Lars-Johan Liman

Halloj igen! Det är idag de sker. Enligt plan släpps den rotzon som har nya signaturer runt kl 16.00 (tiden är inte exakt). Om ni ser skummiteter med era DNS-system efter den tidpunkten, kolla upp att de kör med den nya nyckeln. Om ni ser generalla DNS-problem ute i världen, så vill jag (och vi rotserveroperatorer) gärna veta det också. Mail, SMS eller Signal eller något. Hälsningar /Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #---------------------------------------------------------------------- liman(a)netnod.se 2026-09-12 17:58 [+0200]: > Halloj! > De flesta här är nog med i matchen, men Kim Davies (chefen för IANA) och > jag vill ändå påminna om att Verisign börja signera DNS-roten med en ny > KSK om en månad, den 11 oktober. Det gör att alla resolvrar kommer att > behöva byta till ett nytt "trust anchor". Modern mjukvara sköter det > själv, för den nya nyckeln är redan publicerad sedan länge, och är > korrekt signerad av den gamla. > Det kan möjligen vara läge att hålla ett extra öga på sina resolvrar, > och hålla dem kort, så att de beter sig väluppfostrat. Men det är väl > ingen här som inte kör en automatrullande* resolver? ;-) > Den 11 okt är en söndag, så det kan vara läge med en extra påminnelse i > helgkalendern. > Den nya nyckeln har keyid: 38696 och den gamla nyckeln har keyid: 20326. > Så här kan det se ut om man kör BIND (notera "trusted-since:"): > # rndc managed-keys status > view: _default > next scheduled event: Sun, 13 Sep 2026 08:22:48 GMT > name: . > keyid: 20326 > algorithm: RSASHA256 > flags: SEP > next refresh: Sun, 13 Sep 2026 09:19:57 GMT > trusted since: Sat, 02 Mar 2019 17:12:43 GMT > keyid: 38696 > algorithm: RSASHA256 > flags: SEP > next refresh: Sun, 13 Sep 2026 09:19:57 GMT > trusted since: Mon, 10 Feb 2025 20:30:44 GMT > ... och så här kan det se ut om man kör Unbound (notera "VALID") > (filnamnet kan variera mellan olika varianter av Unix/Linux): > # sed -n -e '/DNSKEY/s/[^;]*;//p' /var/lib/unbound/root.key > {id = 38696 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1739203345 ;;Mon Feb 10 16:02:25 2025 > {id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1553506736 ;;Mon Mar 25 09:38:56 2019 > Om ni _inte_ ser "trusted since:" eller "VALID" (eller motsvarande om ni > kör något annat), så är det läge att börja felsöka och/eller uppdatera nu. > Mer info finns bakom länken i nedanstående mail, eller hojta till här > eller i PM, så skall jag försöka svara på ev. frågor. > Happy rollover! > /Liman > * RFC 5011 rulez! > From: Kim Davies via ksk-rollover <ksk-rollover(a)icann.org> > Subject: [ksk-rollover] Reminder: Root Zone KSK Rollover on October 11 > To: ksk-rollover(a)icann.org > Date: Sat, 12 Sep 2026 17:58:28 +0200 > (4 weeks, 19 hours, 34 seconds ago) > Dear KSK Rollover community, > As we approach the 2026 Root Zone Key Signing Key (KSK) rollover on 11 > October 2026, we wanted to remind you of the upcoming schedule and > encourage you to stay engaged as the rollover approaches. > Information and resources, including technical guidance, FAQs, and the > rollover timeline, are available on the 2026 Root KSK Rollover page at > https://www.icann.org/resources/pages/ksk-rollover-en > We encourage you to use this mailing list to share questions, > observations, or experiences before, during, and following the > rollover. > Thank you for your continued participation and support in helping > ensure a smooth rollover. > Kindest regards, > Kim Davies > VP, IANA Services, ICANN > President, PTI > _______________________________________________ > ksk-rollover mailing list -- ksk-rollover(a)icann.org > To unsubscribe send an email to ksk-rollover-leave(a)icann.org > _______________________________________________ > By submitting your personal data, you consent to the processing of > your personal data for purposes of subscribing to this mailing list > accordance with the ICANN Privacy Policy > (https://www.icann.org/privacy/policy) and the website Terms of > Service (https://www.icann.org/privacy/tos) You can visit the Mailman > link above to change your membership status or configuration, > including unsubscribing, setting digest-style delivery or disabling > delivery altogether (e.g., for a vacation), and so on. > ----------

Oct. 11, 2026

Fwd: Reminder: Root Zone KSK Rollover on October 11

by Lars-Johan Liman

Halloj! De flesta här är nog med i matchen, men Kim Davies (chefen för IANA) och jag vill ändå påminna om att Verisign börja signera DNS-roten med en ny KSK om en månad, den 11 oktober. Det gör att alla resolvrar kommer att behöva byta till ett nytt "trust anchor". Modern mjukvara sköter det själv, för den nya nyckeln är redan publicerad sedan länge, och är korrekt signerad av den gamla. Det kan möjligen vara läge att hålla ett extra öga på sina resolvrar, och hålla dem kort, så att de beter sig väluppfostrat. Men det är väl ingen här som inte kör en automatrullande* resolver? ;-) Den 11 okt är en söndag, så det kan vara läge med en extra påminnelse i helgkalendern. Den nya nyckeln har keyid: 38696 och den gamla nyckeln har keyid: 20326. Så här kan det se ut om man kör BIND (notera "trusted-since:"): # rndc managed-keys status view: _default next scheduled event: Sun, 13 Sep 2026 08:22:48 GMT name: . keyid: 20326 algorithm: RSASHA256 flags: SEP next refresh: Sun, 13 Sep 2026 09:19:57 GMT trusted since: Sat, 02 Mar 2019 17:12:43 GMT keyid: 38696 algorithm: RSASHA256 flags: SEP next refresh: Sun, 13 Sep 2026 09:19:57 GMT trusted since: Mon, 10 Feb 2025 20:30:44 GMT ... och så här kan det se ut om man kör Unbound (notera "VALID") (filnamnet kan variera mellan olika varianter av Unix/Linux): # sed -n -e '/DNSKEY/s/[^;]*;//p' /var/lib/unbound/root.key {id = 38696 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1739203345 ;;Mon Feb 10 16:02:25 2025 {id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1553506736 ;;Mon Mar 25 09:38:56 2019 Om ni _inte_ ser "trusted since:" eller "VALID" (eller motsvarande om ni kör något annat), så är det läge att börja felsöka och/eller uppdatera nu. Mer info finns bakom länken i nedanstående mail, eller hojta till här eller i PM, så skall jag försöka svara på ev. frågor. Happy rollover! /Liman * RFC 5011 rulez! -------------------- Start of forwarded message -------------------- Date: Sat, 12 Sep 2026 07:12:39 -0700 To: ksk-rollover(a)icann.org Subject: [ksk-rollover] Reminder: Root Zone KSK Rollover on October 11 From: Kim Davies via ksk-rollover <ksk-rollover(a)icann.org> Dear KSK Rollover community, As we approach the 2026 Root Zone Key Signing Key (KSK) rollover on 11 October 2026, we wanted to remind you of the upcoming schedule and encourage you to stay engaged as the rollover approaches. Information and resources, including technical guidance, FAQs, and the rollover timeline, are available on the 2026 Root KSK Rollover page at https://www.icann.org/resources/pages/ksk-rollover-en We encourage you to use this mailing list to share questions, observations, or experiences before, during, and following the rollover. Thank you for your continued participation and support in helping ensure a smooth rollover. Kindest regards, Kim Davies VP, IANA Services, ICANN President, PTI _______________________________________________ ksk-rollover mailing list -- ksk-rollover(a)icann.org To unsubscribe send an email to ksk-rollover-leave(a)icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -------------------- End of forwarded message --------------------

Sept. 12, 2026

Re: DS-info via Whois

by Jakob Schlyter

On 2026-08-24 at 19:54, Torbjörn Eklöv via Ns.se wrote: > Jag skulle vilja att samma typ av information syns via en whois mot en .se och .nu domän också. > Är det något som går att ordna? Är det inte enklare att fråga DNS? Eller RDAP ;-) jakob

Aug. 24, 2026

DS-info via Whois

by Torbjörn Eklöv

Hallå listan, vet inte om det här kommer att fungera med den här adressen men jag provar åtminstone. När man kör en whois mot t.ex en .net domän får man med DS-data DNSSEC: signedDelegation DNSSEC DS Data: 18188 13 2B4AC1FE595F941F658EE3CA5A69EA7AF16FB62C36DD183470DD4C84192796586 Jag skulle vilja att samma typ av information syns via en whois mot en .se och .nu domän också. Är det något som går att ordna? //Tobbe - A home without IPv6 is just a house

Aug. 24, 2026

Uppdaterat publiceringsintervall .se

by anders.ek＠internetstiftelsen.se

Hej, Vi har idag uppdaterat publiceringsintervallet för .SE, så från och med nu publiceras se-zonen (minst) 2 gånger per timme. Uppdateringen sker inte med fasta tider, och det nya intervallet är just under 30 minuter. MVH, Anders Ek Internetstiftelsen

Aug. 24, 2026

Re: DNS dagen 2026 - 9 september 2026

by Kristian Ørmen

Hi everyone Please remember to sign up for DNS dagen. And let me know if you have an interesting presentation to share with us. We still have some open spots. https://registryt.wufoo.com/forms/dns-dagen-2026/ Kind regards Kristian Ørmen From: Kristian Ørmen <kristian.ormen(a)internetstiftelsen.se> Date: Saturday, 23 May 2026 at 11.46 To: ns.se(a)lists.iis.se <ns.se(a)lists.iis.se> Subject: DNS dagen 2026 - 9 september 2026 DNS dagen 2026 Välkommen till en dag om bara DNS! Vi ses på Internetstiftelsens kontor den 9 september 2026 kl. 10:00–20:00. Anmäl dig redan idag för att säkra din plats. https://registryt.wufoo.com/forms/dns-dagen-2026/ -- Kristian Ørmen Internetstiftelsen +46 765607953 https://internetstiftelsen.se<https://internetstiftelsen.se/> Besöksadress: Hammarby Kaj 10D, Stockholm Postadress: Box 92073, 120 07 Stockholm

Aug. 6, 2026

Re: DNS-kakor i .se-zonen

by Patrik Wallstrom

Hej! Zonemaster har ju inte detta test - och vad felmeddelandet beror på i alla lägen kan jag ju inte lista ut, även om man kan ha vilda gissningar. Det finns säkert betydligt fler anledningar till att detta test misslyckas. Min inledande gissning med flappande BGP kan ju fortfarande också vara en anledning. Eller att servern helt enkelt är felkonfad på helt andra innovativa sätt. Just texten med förklaringen i användargränssnittet kanske skulle gå att fila till, men jag tror det är betydligt mer arbete än rimligt att försöka gissa på rimliga felorsaker för varje typ av fel som kan uppstå i DNS. / Patrik On Fri, 26 Jun 2026, Lars-Johan Liman wrote: >Halloj! > >Tack för bekräftelsen! Då tror jag vi kan bokföra detta under "begripet, >åtgärd utarbetad, uppköat för genomförande". 🙂 > >Jag håller definitivt med om att default skall vara att köra med >slumpvisa portar, men möjligen skulle det kunna vara just en flagga för >att köra denna form av debugging. Vi är ju inte de enda som kör >lastdelning ... (Även om vi möjligen är de enda som (ännu) inte har >synkroniserat sina cookies ... 😜). > >Ett alternativ skulle kunna vara att informera när felet dyker upp: >"cookie mismatch can be due to cookies not synchrnonised between servers >in a load-balanced cluster", eller något i den stilen. (Å andra sidan >kanske du vill vara strikt med att lämna samma felmeddelanden som >Zonemaster? Då faller ju detta förslag.) > > Glada hälsningar > /Liman > > >pawal(a)amplitut.de 2026-06-26 10:27 [+0200]: >> Hej! > >> Nu har jag testkört samma tester med en enda src-port. Det funkade >> fint, inga felaktigheter upptäcktes då. Inte för att en riktig >> resolver skulle göra så (hoppas jag!), men för att verifiera att det >> var just lastbalanseringen som var problemet. > >> Men jag tänker inte fixa gonemaster till att göra så, inte ens med ett >> val. Eller vore det bra att ha? > >> / Patrik > >> On Thu, 25 Jun 2026, Lars-Johan Liman wrote: > >>> Halloj! >>> >>> Tack för noggrann analys. Nej, det är helt klart att du varken har eller >>> gör fel. Jag beklagar att det blev så mycket jobb för dig. >>> >>> Det vi på Netnod hade att förhålla oss till var om förhållandet är så >>> allvarligt att det motiverar en ändring av vår konfiguration, och vi kom >>> snabbt fram till att ja, det är det. >>> >>> Synkronisering av kakor är ju inte precis rocket science, så vi kommer >>> att rulla ut det, men det är inte säkert att vi hinner genomföra det >>> före sommarens konfigfrys. (Det är trots allt flera hundra servrar ...) >>> >>> Jag tror att lastdelningen sker på kombinationen (src-ip och src-port). >>> Till dess att vi har fixat problemet borde du kunna gå runt problemet >>> genom att se till att din programvara hela tiden sourcar paket från >>> samma IP och port. Det vore iaf. ett intressant test ... 😉 Om du gör >>> det, berätta gärna vad utfallet blev. 🙂 >>> >>> Tack igen! >>> >>> Glada hälsningar >>> /Liman >>> >>> >>> pawal(a)amplitut.de 2026-06-25 13:50 [+0200]: >>>> On 2026-06-24 15:23, Lars-Johan Liman wrote: >>> >>>> Hej Liman och listan! :) >>> >>>> Ja, jag bara förutsatte att det var ett anycast-problem (eftersom det >>>> är det som internet ofta anger när man söker efter DNS Cookie-problem >>>> av detta slaget). Tanken att det fanns en lastbalanserare slog mig >>>> inte, men det har du såklart rätt i att det är det som är problemet. >>> >>>> Lastbalanseraren skulle kunna styra destinations-namnserver med hjälp >>>> av source-IP, men nu verkar det ju som om att det är slumpen som >>>> avgör. Så det är absolut en rimlig förklaring. >>> >>>> Hur viktigt det är att detta problem åtgärdas får er kund avgöra - har >>>> ingen aning om hur era avtal ser ut. Jag tycker mest det är viktigt >>>> att zonen är rätt konfigurerad och att mina verktyg inte gör allt för >>>> stora utslag på varningar och fel. Jag felsökte min egen programvara >>>> rätt länge, och skrev motsvarande i Python, innan jag rapporterade >>>> detta, så jag är rätt säker på att det inte är jag som har fel. :) >>> >>>> / Patrik >>> >>>>> Hej Patrik! >>>>> ("Liman" går bra. Vi behöver väl inte vara så formella between >>>>> friends? >>>>> 😉 Eller är det ett svar på att jag inte skriver "pawal"? 😜) >>>>> Nu har jag bänt rätt på detta i huvudet, tror jag. >>>>> Jag är helt med på ditt resonemang och jag var också där ett kort >>>>> tag >>>>> och vände. Det som drev mig ut på förvirringens hed var det att det är >>>>> så bakvänt att just b.ns.se och c.ns.se _inte_ är anycastade i ordets >>>>> vanliga mening. De två är unicastservrar, om man betraktar dem från >>>>> Internet. >>>>> Som du skriver kan problemet självklart uppstå med vanliga >>>>> anycastservrar om routingen flappar från en site till en annan mellan >>>>> två frågor. Att det händer är dock relativt ovanligt, i synnerhet >>>>> mellan >>>>> två frågor med kort mellanrum, så det "borde" inte uppstå i dina >>>>> körningar. "Och varför i hela friden uppstår det bara på våra >>>>> unicastservrar?!" undrade jag där ute på heden. Innan jag kom på ... >>>>> Vi kör lastdelning på unicastservrarna. Vi har bara en >>>>> "nätverksport" >>>>> mot Internet, så att de upplevs som unicast av klienterna, men bakom >>>>> den >>>>> porten sitter det en lastdelare och flera servrar - av redundans och >>>>> för >>>>> att vi skall kunna serva dem, en i taget. När du ställer frågor till >>>>> det >>>>> du ser som "samma unicastserver" så kommer de att slumpvis hamna på de >>>>> olika maskinerna bakom lastdelaren och _DE_ synkar inte heller cookies >>>>> med varandra. >>>>> BGP-routingen är alltså stabil och du hamnar på samma lastdelare, >>>>> men på >>>>> olika servrar bakom. >>>>> När det gäller de "riktiga" anycastade servrarna i ditt test, så är >>>>> BGP-routingen också stabil och du kommer till samma anycastsite varje >>>>> gång. På varje site finns bara en server, så därför kommer du till >>>>> samma >>>>> faktiska server varje gång och därför funkar cookies. >>>>> Är du med mig? Känns det som en rimlig förklaring till beteendet? >>>>> När det gäller riktig anycast är alltså behovet av att synka cookies >>>>> litet, eftersom BGP flappar tillräcklig sällan för att det inte skall >>>>> vara ett problem när det händer. >>>>> När det gäller lastdelning bakom en och samma unicastadress så blir >>>>> problemet mer uttalat. Det hade vi inte tänkt på. >>>>> Tack för att du hittade detta! Jag tar med mig det som en >>>>> förbättringspunkt och gör en ticket internt för att utreda om vi kan >>>>> göra det på ett funktionsdugligt sätt och i så fall pilla in det. Det >>>>> kanske inte blir före sommaren, dock, om du inte anser att det är ett >>>>> akut problem? >>>>> Glada hälsningar >>>>> /Liman >>>>> pawal(a)amplitut.de 2026-06-24 14:49 [+0200]: >>>>>> Tack för återkopplingen Lars-Johan! >>>>> >>>>>> Den enkla anledningen till att det blir fel är att om man frågar samma >>>>>> namnserver flera gånger så är det inte säkert att man kommer till >>>>>> samma instans (pga Anycast). Därför är det bra om dessa instanser har >>>>>> samma HMAC-hemlisar konfigurerade, så att kakorna blir utbytbara >>>>>> mellan instanserna. >>>>> >>>>>> Nu råkar jag ha otur vid lite för många av testerna i min ursprungliga >>>>>> post, så att efterföljande frågor inte når samma instans, så därför >>>>>> blir kakorna gjorda och verifierade med olika hemlisar. >>>>> >>>>>> För BIND så vill du konfigurera varje instans med med samma >>>>>> "cookie-secret": >>>>>> https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-c… >>>>> >>>>>> / Patrik >>>>> >>>>>> On Wed, 24 Jun 2026, Lars-Johan Liman wrote: >>>>> >>>>>>> Hej Patrik! >>>>>>> Alltid kul med utveckling och alltid springer man in i något! :-) >>>>>>> Såsom dinosaurius technicus för DNS-tjänsten på b.ns.se och >>>>>>> c.ns.se, så >>>>>>> kan jag bekräfta att de inte synkar kakor mellan sig, men jag är inte >>>>>>> riktigt med på varför det skapar problem. Låt mig påminna mig lite >>>>>>> hur >>>>>>> kakor skall funka och kolla lite på hur vi faktiskt gör och >>>>>>> återkomma. >>>>>>> Om vi gör fel får vi försöka fixa. >>>>>>> Glada hälsningar >>>>>>> /Liman >>>>>>> #---------------------------------------------------------------------- >>>>>>> # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)netnod.se >>>>>>> # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 >>>>>>> # Netnod AB, Stockholm ! https://www.netnod.se/ >>>>>>> #---------------------------------------------------------------------- >>>>>>> ns.se(a)lists.iis.se 2026-06-24 11:56 [+0200]: >>>>>>>> Hej! >>>>>>> >>>>>>>> Jag har implementerat tester av DNS Cookies (RFC 7873 / RFC 9018) i >>>>>>>> gonemaster. Och det är uppenbart att det finns ett problem med >>>>>>>> kakorna >>>>>>>> när det gäller uppsättning av Anycast. För .se-zonen märks detta för >>>>>>>> namnservrarna b.ns.se och c.ns.se. I 14 av 20 tester blir det helt >>>>>>>> enkelt fel när man försöker använda en kaka. Anledningen är att >>>>>>>> dessa >>>>>>>> namnservrar inte synkar HMAC-hemlisar mellan sig. >>>>>>> >>>>>>>> Kanske inte någon jättegrej, men en tydlig förbättringsåtgärd. >>>>>>> >>>>>>>> Specificationen: >>>>>>>> https://pawal.codeberg.page/gonemaster/specifications/tests/nameserver/name… >>>>>>> >>>>>>>> Vill man se ett resultat i GUI: >>>>>>>> https://gonemaster.evilbit.de/#/result/OAJB35VX >>>>>>> >>>>>>>> Resultat av 20 körningar av detta testcase med CLI: >>>>>>> >>>>>>>> pawal@dev:~/gonemaster$ for i in {1..20}; do bin/gonemaster >>>>>>>> --testcase nameserver17 se; done >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> Looks OK. >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.40 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "c.ns.se/192.36.135.107". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.49 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/192.36.133.107;b.ns.se/2001:67c:254c:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.46 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.56 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/192.36.133.107". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.48 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/192.36.133.107;c.ns.se/192.36.135.107;c.ns.se/2001:67c:2554:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> Looks OK. >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> Looks OK. >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.38 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/192.36.133.107;c.ns.se/2001:67c:2554:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.43 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> Looks OK. >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.47 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.37 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> Looks OK. >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.50 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "c.ns.se/2001:67c:2554:301::53". >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> Looks OK. >>>>>>>> Seconds Level Message >>>>>>>> ======= ======== ======= >>>>>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>>>> -- >>>>>>>> Ns.se mailing list -- ns.se(a)lists.iis.se >>>>>>>> To unsubscribe send an email to ns.se-leave(a)lists.iis.se

June 26, 2026

Re: DNS-kakor i .se-zonen

by Lars-Johan Liman

Halloj! Tack för bekräftelsen! Då tror jag vi kan bokföra detta under "begripet, åtgärd utarbetad, uppköat för genomförande". 🙂 Jag håller definitivt med om att default skall vara att köra med slumpvisa portar, men möjligen skulle det kunna vara just en flagga för att köra denna form av debugging. Vi är ju inte de enda som kör lastdelning ... (Även om vi möjligen är de enda som (ännu) inte har synkroniserat sina cookies ... 😜). Ett alternativ skulle kunna vara att informera när felet dyker upp: "cookie mismatch can be due to cookies not synchrnonised between servers in a load-balanced cluster", eller något i den stilen. (Å andra sidan kanske du vill vara strikt med att lämna samma felmeddelanden som Zonemaster? Då faller ju detta förslag.) Glada hälsningar /Liman pawal(a)amplitut.de 2026-06-26 10:27 [+0200]: > Hej! > Nu har jag testkört samma tester med en enda src-port. Det funkade > fint, inga felaktigheter upptäcktes då. Inte för att en riktig > resolver skulle göra så (hoppas jag!), men för att verifiera att det > var just lastbalanseringen som var problemet. > Men jag tänker inte fixa gonemaster till att göra så, inte ens med ett > val. Eller vore det bra att ha? > / Patrik > On Thu, 25 Jun 2026, Lars-Johan Liman wrote: >> Halloj! >> >> Tack för noggrann analys. Nej, det är helt klart att du varken har eller >> gör fel. Jag beklagar att det blev så mycket jobb för dig. >> >> Det vi på Netnod hade att förhålla oss till var om förhållandet är så >> allvarligt att det motiverar en ändring av vår konfiguration, och vi kom >> snabbt fram till att ja, det är det. >> >> Synkronisering av kakor är ju inte precis rocket science, så vi kommer >> att rulla ut det, men det är inte säkert att vi hinner genomföra det >> före sommarens konfigfrys. (Det är trots allt flera hundra servrar ...) >> >> Jag tror att lastdelningen sker på kombinationen (src-ip och src-port). >> Till dess att vi har fixat problemet borde du kunna gå runt problemet >> genom att se till att din programvara hela tiden sourcar paket från >> samma IP och port. Det vore iaf. ett intressant test ... 😉 Om du gör >> det, berätta gärna vad utfallet blev. 🙂 >> >> Tack igen! >> >> Glada hälsningar >> /Liman >> >> >> pawal(a)amplitut.de 2026-06-25 13:50 [+0200]: >>> On 2026-06-24 15:23, Lars-Johan Liman wrote: >> >>> Hej Liman och listan! :) >> >>> Ja, jag bara förutsatte att det var ett anycast-problem (eftersom det >>> är det som internet ofta anger när man söker efter DNS Cookie-problem >>> av detta slaget). Tanken att det fanns en lastbalanserare slog mig >>> inte, men det har du såklart rätt i att det är det som är problemet. >> >>> Lastbalanseraren skulle kunna styra destinations-namnserver med hjälp >>> av source-IP, men nu verkar det ju som om att det är slumpen som >>> avgör. Så det är absolut en rimlig förklaring. >> >>> Hur viktigt det är att detta problem åtgärdas får er kund avgöra - har >>> ingen aning om hur era avtal ser ut. Jag tycker mest det är viktigt >>> att zonen är rätt konfigurerad och att mina verktyg inte gör allt för >>> stora utslag på varningar och fel. Jag felsökte min egen programvara >>> rätt länge, och skrev motsvarande i Python, innan jag rapporterade >>> detta, så jag är rätt säker på att det inte är jag som har fel. :) >> >>> / Patrik >> >>>> Hej Patrik! >>>> ("Liman" går bra. Vi behöver väl inte vara så formella between >>>> friends? >>>> 😉 Eller är det ett svar på att jag inte skriver "pawal"? 😜) >>>> Nu har jag bänt rätt på detta i huvudet, tror jag. >>>> Jag är helt med på ditt resonemang och jag var också där ett kort >>>> tag >>>> och vände. Det som drev mig ut på förvirringens hed var det att det är >>>> så bakvänt att just b.ns.se och c.ns.se _inte_ är anycastade i ordets >>>> vanliga mening. De två är unicastservrar, om man betraktar dem från >>>> Internet. >>>> Som du skriver kan problemet självklart uppstå med vanliga >>>> anycastservrar om routingen flappar från en site till en annan mellan >>>> två frågor. Att det händer är dock relativt ovanligt, i synnerhet >>>> mellan >>>> två frågor med kort mellanrum, så det "borde" inte uppstå i dina >>>> körningar. "Och varför i hela friden uppstår det bara på våra >>>> unicastservrar?!" undrade jag där ute på heden. Innan jag kom på ... >>>> Vi kör lastdelning på unicastservrarna. Vi har bara en >>>> "nätverksport" >>>> mot Internet, så att de upplevs som unicast av klienterna, men bakom >>>> den >>>> porten sitter det en lastdelare och flera servrar - av redundans och >>>> för >>>> att vi skall kunna serva dem, en i taget. När du ställer frågor till >>>> det >>>> du ser som "samma unicastserver" så kommer de att slumpvis hamna på de >>>> olika maskinerna bakom lastdelaren och _DE_ synkar inte heller cookies >>>> med varandra. >>>> BGP-routingen är alltså stabil och du hamnar på samma lastdelare, >>>> men på >>>> olika servrar bakom. >>>> När det gäller de "riktiga" anycastade servrarna i ditt test, så är >>>> BGP-routingen också stabil och du kommer till samma anycastsite varje >>>> gång. På varje site finns bara en server, så därför kommer du till >>>> samma >>>> faktiska server varje gång och därför funkar cookies. >>>> Är du med mig? Känns det som en rimlig förklaring till beteendet? >>>> När det gäller riktig anycast är alltså behovet av att synka cookies >>>> litet, eftersom BGP flappar tillräcklig sällan för att det inte skall >>>> vara ett problem när det händer. >>>> När det gäller lastdelning bakom en och samma unicastadress så blir >>>> problemet mer uttalat. Det hade vi inte tänkt på. >>>> Tack för att du hittade detta! Jag tar med mig det som en >>>> förbättringspunkt och gör en ticket internt för att utreda om vi kan >>>> göra det på ett funktionsdugligt sätt och i så fall pilla in det. Det >>>> kanske inte blir före sommaren, dock, om du inte anser att det är ett >>>> akut problem? >>>> Glada hälsningar >>>> /Liman >>>> pawal(a)amplitut.de 2026-06-24 14:49 [+0200]: >>>>> Tack för återkopplingen Lars-Johan! >>>> >>>>> Den enkla anledningen till att det blir fel är att om man frågar samma >>>>> namnserver flera gånger så är det inte säkert att man kommer till >>>>> samma instans (pga Anycast). Därför är det bra om dessa instanser har >>>>> samma HMAC-hemlisar konfigurerade, så att kakorna blir utbytbara >>>>> mellan instanserna. >>>> >>>>> Nu råkar jag ha otur vid lite för många av testerna i min ursprungliga >>>>> post, så att efterföljande frågor inte når samma instans, så därför >>>>> blir kakorna gjorda och verifierade med olika hemlisar. >>>> >>>>> För BIND så vill du konfigurera varje instans med med samma >>>>> "cookie-secret": >>>>> https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-c… >>>> >>>>> / Patrik >>>> >>>>> On Wed, 24 Jun 2026, Lars-Johan Liman wrote: >>>> >>>>>> Hej Patrik! >>>>>> Alltid kul med utveckling och alltid springer man in i något! :-) >>>>>> Såsom dinosaurius technicus för DNS-tjänsten på b.ns.se och >>>>>> c.ns.se, så >>>>>> kan jag bekräfta att de inte synkar kakor mellan sig, men jag är inte >>>>>> riktigt med på varför det skapar problem. Låt mig påminna mig lite >>>>>> hur >>>>>> kakor skall funka och kolla lite på hur vi faktiskt gör och >>>>>> återkomma. >>>>>> Om vi gör fel får vi försöka fixa. >>>>>> Glada hälsningar >>>>>> /Liman >>>>>> #---------------------------------------------------------------------- >>>>>> # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)netnod.se >>>>>> # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 >>>>>> # Netnod AB, Stockholm ! https://www.netnod.se/ >>>>>> #---------------------------------------------------------------------- >>>>>> ns.se(a)lists.iis.se 2026-06-24 11:56 [+0200]: >>>>>>> Hej! >>>>>> >>>>>>> Jag har implementerat tester av DNS Cookies (RFC 7873 / RFC 9018) i >>>>>>> gonemaster. Och det är uppenbart att det finns ett problem med >>>>>>> kakorna >>>>>>> när det gäller uppsättning av Anycast. För .se-zonen märks detta för >>>>>>> namnservrarna b.ns.se och c.ns.se. I 14 av 20 tester blir det helt >>>>>>> enkelt fel när man försöker använda en kaka. Anledningen är att >>>>>>> dessa >>>>>>> namnservrar inte synkar HMAC-hemlisar mellan sig. >>>>>> >>>>>>> Kanske inte någon jättegrej, men en tydlig förbättringsåtgärd. >>>>>> >>>>>>> Specificationen: >>>>>>> https://pawal.codeberg.page/gonemaster/specifications/tests/nameserver/name… >>>>>> >>>>>>> Vill man se ett resultat i GUI: >>>>>>> https://gonemaster.evilbit.de/#/result/OAJB35VX >>>>>> >>>>>>> Resultat av 20 körningar av detta testcase med CLI: >>>>>> >>>>>>> pawal@dev:~/gonemaster$ for i in {1..20}; do bin/gonemaster >>>>>>> --testcase nameserver17 se; done >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> Looks OK. >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.40 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "c.ns.se/192.36.135.107". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.49 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/192.36.133.107;b.ns.se/2001:67c:254c:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.46 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.56 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/192.36.133.107". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.48 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/192.36.133.107;c.ns.se/192.36.135.107;c.ns.se/2001:67c:2554:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> Looks OK. >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> Looks OK. >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.38 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/192.36.133.107;c.ns.se/2001:67c:2554:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.43 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> Looks OK. >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.47 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.37 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> Looks OK. >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.50 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "c.ns.se/2001:67c:2554:301::53". >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> Looks OK. >>>>>>> Seconds Level Message >>>>>>> ======= ======== ======= >>>>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>>> -- >>>>>>> Ns.se mailing list -- ns.se(a)lists.iis.se >>>>>>> To unsubscribe send an email to ns.se-leave(a)lists.iis.se

June 26, 2026

Re: DNS-kakor i .se-zonen

by Patrik Wallstrom

Hej! Nu har jag testkört samma tester med en enda src-port. Det funkade fint, inga felaktigheter upptäcktes då. Inte för att en riktig resolver skulle göra så (hoppas jag!), men för att verifiera att det var just lastbalanseringen som var problemet. Men jag tänker inte fixa gonemaster till att göra så, inte ens med ett val. Eller vore det bra att ha? / Patrik On Thu, 25 Jun 2026, Lars-Johan Liman wrote: >Halloj! > >Tack för noggrann analys. Nej, det är helt klart att du varken har eller >gör fel. Jag beklagar att det blev så mycket jobb för dig. > >Det vi på Netnod hade att förhålla oss till var om förhållandet är så >allvarligt att det motiverar en ändring av vår konfiguration, och vi kom >snabbt fram till att ja, det är det. > >Synkronisering av kakor är ju inte precis rocket science, så vi kommer >att rulla ut det, men det är inte säkert att vi hinner genomföra det >före sommarens konfigfrys. (Det är trots allt flera hundra servrar ...) > >Jag tror att lastdelningen sker på kombinationen (src-ip och src-port). >Till dess att vi har fixat problemet borde du kunna gå runt problemet >genom att se till att din programvara hela tiden sourcar paket från >samma IP och port. Det vore iaf. ett intressant test ... 😉 Om du gör >det, berätta gärna vad utfallet blev. 🙂 > >Tack igen! > > Glada hälsningar > /Liman > > >pawal(a)amplitut.de 2026-06-25 13:50 [+0200]: >> On 2026-06-24 15:23, Lars-Johan Liman wrote: > >> Hej Liman och listan! :) > >> Ja, jag bara förutsatte att det var ett anycast-problem (eftersom det >> är det som internet ofta anger när man söker efter DNS Cookie-problem >> av detta slaget). Tanken att det fanns en lastbalanserare slog mig >> inte, men det har du såklart rätt i att det är det som är problemet. > >> Lastbalanseraren skulle kunna styra destinations-namnserver med hjälp >> av source-IP, men nu verkar det ju som om att det är slumpen som >> avgör. Så det är absolut en rimlig förklaring. > >> Hur viktigt det är att detta problem åtgärdas får er kund avgöra - har >> ingen aning om hur era avtal ser ut. Jag tycker mest det är viktigt >> att zonen är rätt konfigurerad och att mina verktyg inte gör allt för >> stora utslag på varningar och fel. Jag felsökte min egen programvara >> rätt länge, och skrev motsvarande i Python, innan jag rapporterade >> detta, så jag är rätt säker på att det inte är jag som har fel. :) > >> / Patrik > >>> Hej Patrik! >>> ("Liman" går bra. Vi behöver väl inte vara så formella between >>> friends? >>> 😉 Eller är det ett svar på att jag inte skriver "pawal"? 😜) >>> Nu har jag bänt rätt på detta i huvudet, tror jag. >>> Jag är helt med på ditt resonemang och jag var också där ett kort >>> tag >>> och vände. Det som drev mig ut på förvirringens hed var det att det är >>> så bakvänt att just b.ns.se och c.ns.se _inte_ är anycastade i ordets >>> vanliga mening. De två är unicastservrar, om man betraktar dem från >>> Internet. >>> Som du skriver kan problemet självklart uppstå med vanliga >>> anycastservrar om routingen flappar från en site till en annan mellan >>> två frågor. Att det händer är dock relativt ovanligt, i synnerhet >>> mellan >>> två frågor med kort mellanrum, så det "borde" inte uppstå i dina >>> körningar. "Och varför i hela friden uppstår det bara på våra >>> unicastservrar?!" undrade jag där ute på heden. Innan jag kom på ... >>> Vi kör lastdelning på unicastservrarna. Vi har bara en >>> "nätverksport" >>> mot Internet, så att de upplevs som unicast av klienterna, men bakom >>> den >>> porten sitter det en lastdelare och flera servrar - av redundans och >>> för >>> att vi skall kunna serva dem, en i taget. När du ställer frågor till >>> det >>> du ser som "samma unicastserver" så kommer de att slumpvis hamna på de >>> olika maskinerna bakom lastdelaren och _DE_ synkar inte heller cookies >>> med varandra. >>> BGP-routingen är alltså stabil och du hamnar på samma lastdelare, >>> men på >>> olika servrar bakom. >>> När det gäller de "riktiga" anycastade servrarna i ditt test, så är >>> BGP-routingen också stabil och du kommer till samma anycastsite varje >>> gång. På varje site finns bara en server, så därför kommer du till >>> samma >>> faktiska server varje gång och därför funkar cookies. >>> Är du med mig? Känns det som en rimlig förklaring till beteendet? >>> När det gäller riktig anycast är alltså behovet av att synka cookies >>> litet, eftersom BGP flappar tillräcklig sällan för att det inte skall >>> vara ett problem när det händer. >>> När det gäller lastdelning bakom en och samma unicastadress så blir >>> problemet mer uttalat. Det hade vi inte tänkt på. >>> Tack för att du hittade detta! Jag tar med mig det som en >>> förbättringspunkt och gör en ticket internt för att utreda om vi kan >>> göra det på ett funktionsdugligt sätt och i så fall pilla in det. Det >>> kanske inte blir före sommaren, dock, om du inte anser att det är ett >>> akut problem? >>> Glada hälsningar >>> /Liman >>> pawal(a)amplitut.de 2026-06-24 14:49 [+0200]: >>>> Tack för återkopplingen Lars-Johan! >>> >>>> Den enkla anledningen till att det blir fel är att om man frågar samma >>>> namnserver flera gånger så är det inte säkert att man kommer till >>>> samma instans (pga Anycast). Därför är det bra om dessa instanser har >>>> samma HMAC-hemlisar konfigurerade, så att kakorna blir utbytbara >>>> mellan instanserna. >>> >>>> Nu råkar jag ha otur vid lite för många av testerna i min ursprungliga >>>> post, så att efterföljande frågor inte når samma instans, så därför >>>> blir kakorna gjorda och verifierade med olika hemlisar. >>> >>>> För BIND så vill du konfigurera varje instans med med samma >>>> "cookie-secret": >>>> https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-c… >>> >>>> / Patrik >>> >>>> On Wed, 24 Jun 2026, Lars-Johan Liman wrote: >>> >>>>> Hej Patrik! >>>>> Alltid kul med utveckling och alltid springer man in i något! :-) >>>>> Såsom dinosaurius technicus för DNS-tjänsten på b.ns.se och >>>>> c.ns.se, så >>>>> kan jag bekräfta att de inte synkar kakor mellan sig, men jag är inte >>>>> riktigt med på varför det skapar problem. Låt mig påminna mig lite >>>>> hur >>>>> kakor skall funka och kolla lite på hur vi faktiskt gör och >>>>> återkomma. >>>>> Om vi gör fel får vi försöka fixa. >>>>> Glada hälsningar >>>>> /Liman >>>>> #---------------------------------------------------------------------- >>>>> # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)netnod.se >>>>> # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 >>>>> # Netnod AB, Stockholm ! https://www.netnod.se/ >>>>> #---------------------------------------------------------------------- >>>>> ns.se(a)lists.iis.se 2026-06-24 11:56 [+0200]: >>>>>> Hej! >>>>> >>>>>> Jag har implementerat tester av DNS Cookies (RFC 7873 / RFC 9018) i >>>>>> gonemaster. Och det är uppenbart att det finns ett problem med >>>>>> kakorna >>>>>> när det gäller uppsättning av Anycast. För .se-zonen märks detta för >>>>>> namnservrarna b.ns.se och c.ns.se. I 14 av 20 tester blir det helt >>>>>> enkelt fel när man försöker använda en kaka. Anledningen är att >>>>>> dessa >>>>>> namnservrar inte synkar HMAC-hemlisar mellan sig. >>>>> >>>>>> Kanske inte någon jättegrej, men en tydlig förbättringsåtgärd. >>>>> >>>>>> Specificationen: >>>>>> https://pawal.codeberg.page/gonemaster/specifications/tests/nameserver/name… >>>>> >>>>>> Vill man se ett resultat i GUI: >>>>>> https://gonemaster.evilbit.de/#/result/OAJB35VX >>>>> >>>>>> Resultat av 20 körningar av detta testcase med CLI: >>>>> >>>>>> pawal@dev:~/gonemaster$ for i in {1..20}; do bin/gonemaster >>>>>> --testcase nameserver17 se; done >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> Looks OK. >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.40 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "c.ns.se/192.36.135.107". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.49 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/192.36.133.107;b.ns.se/2001:67c:254c:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.46 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.56 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/192.36.133.107". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.48 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/192.36.133.107;c.ns.se/192.36.135.107;c.ns.se/2001:67c:2554:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> Looks OK. >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> Looks OK. >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.38 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/192.36.133.107;c.ns.se/2001:67c:2554:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.43 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> Looks OK. >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.47 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.37 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> Looks OK. >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.50 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "c.ns.se/2001:67c:2554:301::53". >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> Looks OK. >>>>>> Seconds Level Message >>>>>> ======= ======== ======= >>>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>>> -- >>>>>> Ns.se mailing list -- ns.se(a)lists.iis.se >>>>>> To unsubscribe send an email to ns.se-leave(a)lists.iis.se

June 26, 2026

Re: DNS-kakor i .se-zonen

by Lars-Johan Liman

Halloj! Tack för noggrann analys. Nej, det är helt klart att du varken har eller gör fel. Jag beklagar att det blev så mycket jobb för dig. Det vi på Netnod hade att förhålla oss till var om förhållandet är så allvarligt att det motiverar en ändring av vår konfiguration, och vi kom snabbt fram till att ja, det är det. Synkronisering av kakor är ju inte precis rocket science, så vi kommer att rulla ut det, men det är inte säkert att vi hinner genomföra det före sommarens konfigfrys. (Det är trots allt flera hundra servrar ...) Jag tror att lastdelningen sker på kombinationen (src-ip och src-port). Till dess att vi har fixat problemet borde du kunna gå runt problemet genom att se till att din programvara hela tiden sourcar paket från samma IP och port. Det vore iaf. ett intressant test ... 😉 Om du gör det, berätta gärna vad utfallet blev. 🙂 Tack igen! Glada hälsningar /Liman pawal(a)amplitut.de 2026-06-25 13:50 [+0200]: > On 2026-06-24 15:23, Lars-Johan Liman wrote: > Hej Liman och listan! :) > Ja, jag bara förutsatte att det var ett anycast-problem (eftersom det > är det som internet ofta anger när man söker efter DNS Cookie-problem > av detta slaget). Tanken att det fanns en lastbalanserare slog mig > inte, men det har du såklart rätt i att det är det som är problemet. > Lastbalanseraren skulle kunna styra destinations-namnserver med hjälp > av source-IP, men nu verkar det ju som om att det är slumpen som > avgör. Så det är absolut en rimlig förklaring. > Hur viktigt det är att detta problem åtgärdas får er kund avgöra - har > ingen aning om hur era avtal ser ut. Jag tycker mest det är viktigt > att zonen är rätt konfigurerad och att mina verktyg inte gör allt för > stora utslag på varningar och fel. Jag felsökte min egen programvara > rätt länge, och skrev motsvarande i Python, innan jag rapporterade > detta, så jag är rätt säker på att det inte är jag som har fel. :) > / Patrik >> Hej Patrik! >> ("Liman" går bra. Vi behöver väl inte vara så formella between >> friends? >> 😉 Eller är det ett svar på att jag inte skriver "pawal"? 😜) >> Nu har jag bänt rätt på detta i huvudet, tror jag. >> Jag är helt med på ditt resonemang och jag var också där ett kort >> tag >> och vände. Det som drev mig ut på förvirringens hed var det att det är >> så bakvänt att just b.ns.se och c.ns.se _inte_ är anycastade i ordets >> vanliga mening. De två är unicastservrar, om man betraktar dem från >> Internet. >> Som du skriver kan problemet självklart uppstå med vanliga >> anycastservrar om routingen flappar från en site till en annan mellan >> två frågor. Att det händer är dock relativt ovanligt, i synnerhet >> mellan >> två frågor med kort mellanrum, så det "borde" inte uppstå i dina >> körningar. "Och varför i hela friden uppstår det bara på våra >> unicastservrar?!" undrade jag där ute på heden. Innan jag kom på ... >> Vi kör lastdelning på unicastservrarna. Vi har bara en >> "nätverksport" >> mot Internet, så att de upplevs som unicast av klienterna, men bakom >> den >> porten sitter det en lastdelare och flera servrar - av redundans och >> för >> att vi skall kunna serva dem, en i taget. När du ställer frågor till >> det >> du ser som "samma unicastserver" så kommer de att slumpvis hamna på de >> olika maskinerna bakom lastdelaren och _DE_ synkar inte heller cookies >> med varandra. >> BGP-routingen är alltså stabil och du hamnar på samma lastdelare, >> men på >> olika servrar bakom. >> När det gäller de "riktiga" anycastade servrarna i ditt test, så är >> BGP-routingen också stabil och du kommer till samma anycastsite varje >> gång. På varje site finns bara en server, så därför kommer du till >> samma >> faktiska server varje gång och därför funkar cookies. >> Är du med mig? Känns det som en rimlig förklaring till beteendet? >> När det gäller riktig anycast är alltså behovet av att synka cookies >> litet, eftersom BGP flappar tillräcklig sällan för att det inte skall >> vara ett problem när det händer. >> När det gäller lastdelning bakom en och samma unicastadress så blir >> problemet mer uttalat. Det hade vi inte tänkt på. >> Tack för att du hittade detta! Jag tar med mig det som en >> förbättringspunkt och gör en ticket internt för att utreda om vi kan >> göra det på ett funktionsdugligt sätt och i så fall pilla in det. Det >> kanske inte blir före sommaren, dock, om du inte anser att det är ett >> akut problem? >> Glada hälsningar >> /Liman >> pawal(a)amplitut.de 2026-06-24 14:49 [+0200]: >>> Tack för återkopplingen Lars-Johan! >> >>> Den enkla anledningen till att det blir fel är att om man frågar samma >>> namnserver flera gånger så är det inte säkert att man kommer till >>> samma instans (pga Anycast). Därför är det bra om dessa instanser har >>> samma HMAC-hemlisar konfigurerade, så att kakorna blir utbytbara >>> mellan instanserna. >> >>> Nu råkar jag ha otur vid lite för många av testerna i min ursprungliga >>> post, så att efterföljande frågor inte når samma instans, så därför >>> blir kakorna gjorda och verifierade med olika hemlisar. >> >>> För BIND så vill du konfigurera varje instans med med samma >>> "cookie-secret": >>> https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-c… >> >>> / Patrik >> >>> On Wed, 24 Jun 2026, Lars-Johan Liman wrote: >> >>>> Hej Patrik! >>>> Alltid kul med utveckling och alltid springer man in i något! :-) >>>> Såsom dinosaurius technicus för DNS-tjänsten på b.ns.se och >>>> c.ns.se, så >>>> kan jag bekräfta att de inte synkar kakor mellan sig, men jag är inte >>>> riktigt med på varför det skapar problem. Låt mig påminna mig lite >>>> hur >>>> kakor skall funka och kolla lite på hur vi faktiskt gör och >>>> återkomma. >>>> Om vi gör fel får vi försöka fixa. >>>> Glada hälsningar >>>> /Liman >>>> #---------------------------------------------------------------------- >>>> # Lars-Johan Liman, M.Sc. ! E-mail: liman(a)netnod.se >>>> # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 >>>> # Netnod AB, Stockholm ! https://www.netnod.se/ >>>> #---------------------------------------------------------------------- >>>> ns.se(a)lists.iis.se 2026-06-24 11:56 [+0200]: >>>>> Hej! >>>> >>>>> Jag har implementerat tester av DNS Cookies (RFC 7873 / RFC 9018) i >>>>> gonemaster. Och det är uppenbart att det finns ett problem med >>>>> kakorna >>>>> när det gäller uppsättning av Anycast. För .se-zonen märks detta för >>>>> namnservrarna b.ns.se och c.ns.se. I 14 av 20 tester blir det helt >>>>> enkelt fel när man försöker använda en kaka. Anledningen är att >>>>> dessa >>>>> namnservrar inte synkar HMAC-hemlisar mellan sig. >>>> >>>>> Kanske inte någon jättegrej, men en tydlig förbättringsåtgärd. >>>> >>>>> Specificationen: >>>>> https://pawal.codeberg.page/gonemaster/specifications/tests/nameserver/name… >>>> >>>>> Vill man se ett resultat i GUI: >>>>> https://gonemaster.evilbit.de/#/result/OAJB35VX >>>> >>>>> Resultat av 20 körningar av detta testcase med CLI: >>>> >>>>> pawal@dev:~/gonemaster$ for i in {1..20}; do bin/gonemaster >>>>> --testcase nameserver17 se; done >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> Looks OK. >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.40 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "c.ns.se/192.36.135.107". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.49 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/192.36.133.107;b.ns.se/2001:67c:254c:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.46 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.56 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/192.36.133.107". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.48 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/192.36.133.107;c.ns.se/192.36.135.107;c.ns.se/2001:67c:2554:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> Looks OK. >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> Looks OK. >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.38 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/192.36.133.107;c.ns.se/2001:67c:2554:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.43 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/192.36.135.107". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> Looks OK. >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.47 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.42 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.37 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> Looks OK. >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.50 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "c.ns.se/2001:67c:2554:301::53". >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> Looks OK. >>>>> Seconds Level Message >>>>> ======= ======== ======= >>>>> 3.45 WARNING The following name server(s) rejected with BADCOOKIE, >>>>> even after a retry, a Server Cookie they had just issued (RFC 7873): >>>>> "b.ns.se/2001:67c:254c:301::53;c.ns.se/2001:67c:2554:301::53". >>>>> -- >>>>> Ns.se mailing list -- ns.se(a)lists.iis.se >>>>> To unsubscribe send an email to ns.se-leave(a)lists.iis.se

June 25, 2026