[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-ns-revalidation-07.txt

my bad, forgot to add the ref: [0] https://par.nsf.gov/servlets/purl/10186683 or https://catalog.caida.org/paper/2020_when_parents_children_disagree On 08-07-2024 12:55, Giovane C. M. Moura wrote: Hi Willem, We've got a peer-reviewed reference[0]  that can help back up some of the claims

[DNSOP] Re: Fwd: New Version Notification for draft-ietf-dnsop-ns-revalidation-07.txt

Hi Willem, We've got a peer-reviewed reference[0] that can help back up some of the claims in the draft. ``` 2. Motivation There is wide variability in the behavior of deployed DNS resolvers today with respect to how they process delegation records. Some of them prefer the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-07.txt

Hello, > Please review current verion. I have two data points to back some of your claims: "EDNS0 is now widely deployed" * We have some data to back this claim up -- but only from a ccTLD authoritative DNS vantage point. In short: 90% of the queries .nl sees have EDNS0. See data in [0].(if

Re: [DNSOP] draft-moura-dnsop-negative-cache-loop

Thanks Ralf, > I fully agree here. Most of the current or older implementations > solve this by resource limiting and had no problem with tsuName. Only > some new cloud implementations had a problems. So please don’t > require those that had working mitigations to change them. Well, not only

Re: [DNSOP] draft-moura-dnsop-negative-cache-loop

Thanks a lot, Petr. > > If I understand this correctly, TL;DR summary essentially is > """ make https://datatracker.ietf.org/doc/html/rfc2308#section-7.1 > mandatory """ > (even though your version is a bit stronger). Is that correct? > Thanks for pointing to this section. We missed it. We

[DNSOP] draft-moura-dnsop-negative-cache-loop

what folks have to say. Thanks, /giovane Giovane C.M. Moura SIDN Labs [0] https://tsuname.io [1] https://www.isi.edu/~johnh/PAPERS/Moura21b.pdf -- A new version of I-D, draft-moura-dnsop-negative-cache-loop-00.txt has been successfully submitted by Giovane C. M. Moura and posted to the IETF

Re: [DNSOP] New draft on delegation revalidation

Hi Shumon, > Thanks Giovane (and Marco)! Sure thing. > The HTTPS site goes to a different and mostly empty page - and > Chrome doesn't like the certificate because it has a wildcard Subject > CN. Are you planning to fix that? fixed. > I know DNSSEC is likely not the focus of your experiment,

Re: [DNSOP] New draft on delegation revalidation

>> Do you plan to maintain the parent/child disjoint NS  >> domain (marigliano.xyz ) going forward? And what >> about the test >> domains for other types of misconfigurations? > > Great idea. Let me look into this, will get back to with that. Done. Check

Re: [DNSOP] New draft on delegation revalidation

> I meant servers within the child (or parent) NS set had different NS > sets configured in them, i.e. yet another level of mismatch. Maybe > that's not worth investigating, but I'm pretty sure I've come across > such misconfigurations in the past. Oh now I get it. We did only with a sample of

Re: [DNSOP] New draft on delegation revalidation

Hi Shumon, > Do you plan to maintain the parent/child disjoint NS  > domain (marigliano.xyz ) going forward? And what > about the test > domains for other types of misconfigurations? Great idea. Let me look into this, will get back to with that. > Did you look at the

Re: [DNSOP] New draft on delegation revalidation

Hi Shumon, > The main recommendations in the draft are to: (1) deterministically > prefer the authoritative child NS set over the non-authoritative, > unsigned, delegating NS set in the parent This was a problem waiting to be addressed for a long time. Thanks for writing this. For what is

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-terminology-bis-11

Thanks Paul, > First: we were probably sloppy in the use of the word "answer". In > many cases, that should be "response". Thanks for clarifying it, and don't get me wrong, it's not only this draft that had this -- many academic papers do the same (including mine) -- but since this is a

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-terminology-bis-11

Maybe I am missing something, but it seems to be that the term 'answers' and 'response' are currently being used interchangeably in the draft. I opened a issue on Github for that, with an example. https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/70 /giovane

[DNSOP] 4 DNS presentations on MAPRG (Thu 9:30 @Place du Canada)

Hello Folks, So in the end of today's session, I briefly mention that there will be 4 presentations on MAPRG tomorrow about DNS. After that, some people told me they'd would have liked to know a bit more these presentations and the group itself, since many people on DNSOP may not be aware of

[DNSOP] tech report on ' dissecting DNS defenses during DDoS'

Folks, We have a new tech report that analyzes DNS defenses during DDoS atacks using controlled experiments and production data. Some of you may find it interesting. PDF: https://isi.edu/~johnh/PAPERS/Moura18a.pdf Ripe Atlas blog:

Re: [DNSOP] Measuring DNS TTL clamping in the wild

Hi, >>> We are getting into religion here, the original poster called people that >>> cap TTL's Heretics, >> >> Looking through the mail archives, no one other than you is using that term. > > I think this is subject to interpretation, some people view the done > differently. > The subject

[DNSOP] Measuring DNS TTL Violations in the wild

Hi, In the light of the recent discussions on TTL violations and server stale here on the list, I decided to take a look on how often resolvers perform TTL violations in the wild. To do that, I used almost 10K Ripe Atlas probes. You can find a report and datasets at:

[DNSOP] ENTRADA goes open source (.nl Hadoop platform)

* ENTRADA GOES OPEN SOURCE http://entrada.sidnlabs.nl/ * SIDN Labs [1] is happy to announce that we are releasing our ENTRADA platform as an open source project [2]. ENTRADA is

Re: [DNSOP] Open Aggregated Datasets and stats on DNS (.NL ccTLD)

> I'd be curious to know what you're seeing for the dominant "_" >> number in the observed TLSA queries, and whether any particular >> resolvers are responsible for the bulk of the "_25" queries. In the previous e-mail I sent the client's source ports counts, in addition to the counts per IP.

[DNSOP] Open Aggregated Datasets and stats on DNS (.NL ccTLD)

/tx_sidnpublications/SIDN_Labs_Privacyraamwerk_Position_Paper_V1.4_ENG.pdf [4] https://www.sidn.nl/ [5] https://www.sidnlabs.nl/uploads/tx_sidnpublications/NCSC-presentatie-BIG-data-pub.pdf Giovane C. M. Moura, PhD. |Data Scientist|SIDN Labs SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM giovane.mo