We plan to implement #JSON output in our #DNS investigation tool dnsi. There is informational RFC 8427 for representing DNS messages in JSON, but we’d like to see if there is a more ergonomic way of representing such a format. We'd love to hear about your use cases and wishes. https://github.com/NLnetLabs/dnsi/issues/12
"Because of the lack of clear signals of general adoption of DNSSEC over three decades, is it time to acknowledge that DNSSEC is just not going anywhere? Is it time to call it a day for DNSSEC and just move on?"
Quand bien même vous tombez sur une des plateformes "whois", on est pas sûr de la fraîcheur de l'information… (et y a pas d'odorama sur le web, pas comme à la poissonnerie)
@jpmens I wanted a signed SOA returned, which could be used for TTL stretching by caches if allowed by the zone administrator.
For example, if I lookup a record in version X of a zone, then later look up a different record in the same zone and discover that it is still version X, then I can reset the TTL for the first record as if I had just looked it up.
@shane_kerr@jpmens I just had the opposite train of thought: (aggressively) discard all cached entries when I know a zone has been updated (increased ZONEVERSION).
Maybe this could make the CDNs stop using dramatically low #DNS TTLs on all their records, just in case they might update their zone (or we could more comfortably use higher min-ttl values).
I also some potential to limit of outages caused by #DNSSEC bad practice.
C'est pendant les pannes qu'on peut le mieux observer comment un système marche. Les perturbations qui affectent le serveur racine du #DNS identifié par la lettre C sont donc l'occasion d'apprendre comment fonctionne ce système des serveurs racine.
@krysztophe Juste dans l'article, je suis cité à la fin.
Après, j'ai géré les serveurs d'authorité de Gandi et le réseau anycast associé. Donc je pense qu'on peut aussi dire qu'il y a des bouts de moi dans le DNS :p
Au RIPE de Cracovie j'ai aussi commencé les discussions avec PCH pour avoir un pop à Rennes.
Są tu spece od Dockera? Próbuję uruchomić kontener Dockera używają Podmana (https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md), ale utknąłem. Po wielu próbach, kombinowaniu, aktualizacji setek programów, utknąłem na niemożności uruchomienia kontenera, bo twierdzi, że port 53/tcp jest w użyciu. Zrobiłęm już chyba wszystko, co mi wpadło do głowy, czyli wyłączenie systemd, wyłączenie nasłuchiwania przez systemd na porcie 53 i nic to nie daje. Co ciekawe, netstat nie pokazuje portu 53 jakoby był w użyciu, więc nie wiem nawet, jaki program może tego używać. Co ciekawe, jak wziąłem nmapa z innego hosta, to pokazuje, ze port 53 jest zamkniety, wiec cos tam nasluchuje, ale nie wiem co.
Podobno podman używa jakiegoś własnego serwera DNS do zarządzania siecią między kontenerami, ale nie ogarniam tego, a i nie wiem, czy tu może być problem. Poza tym serwerem podmana, nie przychodzi mi juz nic do glowy.
@centopus@linux_pl
Ja miałem taką sytuację, że kiedyś instałowałem drivery do dwóch urządzeń. drivery do jednego urządzenia chodziły na kernelu nie nowszym niż XXX, a drugie urządzenie było dość nowe, więc sterowniki były w kernelu, ale jednym z nowszych, więc miałem zabawę w szukanie kernela, który będzie działał z oboma urządzeniami.
Co do dnsmasq, to ważne, że już działa. Martwi mnie tylko ta zwiecha. Kiedyś mi się takie coś wydarzyło, jak byłem poza domem 3 tygodnie i przeszło 2 tygodnie nie miałem dostępu do serwera.