Ns.se

By thread

ns.se@lists.iis.se

June 2026

3 participants
10 messages

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

Re: DNS-kakor i .se-zonen

by Patrik Wallström

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

Re: DNS-kakor i .se-zonen

by Lars-Johan Liman

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 24, 2026

Re: DNS-kakor i .se-zonen

by Patrik Wallstrom

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 24, 2026

Re: DNS-kakor i .se-zonen

by Lars-Johan Liman

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 24, 2026

DNS-kakor i .se-zonen

by Patrik Wallstrom

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".

June 24, 2026

DNS TAPIR Afterwork

by Olle E. Johansson

Hej! Sommaren är här och vi tapirer släpps snart ut på grönbete. Men innan dess vill vi träffa så många som möjligt av er och berätta om vad vi gjort i vår, vart vi är på väg och snacka lite DNS och Internet och sånt. Välkommen till DNS TAPIR Afterwork på Netnod i Filmstaden i Solna! Tisdagen den 16 juni kl 15:00 drar vi igång. En stund senare håller vi en liten uppdatering men sedan är det bara mingel. Anmäl dig till info(a)dnstapir.se så vi kan beräkna plats och andra resurser :-) Netnod hittar ni på Greta Garbos väg 13 i Solna. Närmsta T-bana är Näckrosen. Vi ser fram emot att träffa dig igen! För DNS TAPIR /Olle

June 1, 2026