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