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/names... 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".
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@netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #---------------------------------------------------------------------- ns.se@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/names...
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@lists.iis.se To unsubscribe send an email to ns.se-leave@lists.iis.se
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-co... / 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@netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #----------------------------------------------------------------------
ns.se@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/names...
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@lists.iis.se To unsubscribe send an email to ns.se-leave@lists.iis.se
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@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-co...
/ 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@netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #----------------------------------------------------------------------
ns.se@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/names...
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@lists.iis.se To unsubscribe send an email to ns.se-leave@lists.iis.se
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@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-co...
/ 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@netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #----------------------------------------------------------------------
ns.se@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/names...
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@lists.iis.se To unsubscribe send an email to ns.se-leave@lists.iis.se
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@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@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-co...
/ 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@netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #---------------------------------------------------------------------- ns.se@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/names...
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@lists.iis.se To unsubscribe send an email to ns.se-leave@lists.iis.se
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@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@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-co...
/ 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@netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #---------------------------------------------------------------------- ns.se@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/names...
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@lists.iis.se To unsubscribe send an email to ns.se-leave@lists.iis.se
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@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@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@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-co...
/ 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@netnod.se # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 # Netnod AB, Stockholm ! https://www.netnod.se/ #---------------------------------------------------------------------- ns.se@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/names...
> 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@lists.iis.se > To unsubscribe send an email to ns.se-leave@lists.iis.se
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@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@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@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-co...
/ 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@netnod.se > # Senior Systems Specialist ! Mobile: +46 708 - 54 06 66 > # Netnod AB, Stockholm ! https://www.netnod.se/ > #---------------------------------------------------------------------- > ns.se@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/names... > >> 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@lists.iis.se >> To unsubscribe send an email to ns.se-leave@lists.iis.se
participants (2)
-
Lars-Johan Liman -
Patrik Wallstrom