Based in Arnhem, The Netherlands
Articles
Likes on articles
Giovane is a Data Scientist with SIDN Labs (.nl registry) and Guest Researcher at TU Delft, in the Netherlands. He works on security and Internet measurements research projects. Prior to SIDN, he worked as a Postdoctoral Researcher at Delft University of Technology, in The Netherlands. He obtained his Ph.D. degree with Prof. Aiko Pras at the University of Twente, also in the Netherlands, with focus on both active and passive Internet measurements. His research interests include Internet Measurements, Management, Security and Machine Learning applications. You can reach him at http://giovane-moura.nl/
Website: http://giovane-moura.nl/
Electronic government (e-gov) lets citizens interact with their government via the Internet. The DNS, which maps e-gov domain names to Internet addresses, underpins e-gov. Working with the University of Twente and NCSC-NL, SIDN Labs compare the resiliency and redundancy of e-gov domains for the Net…
RFC 9199 puts forward six considerations for large authoritative DNS server operators each derived from peer-reviewed research. Giovane Moura from SIDN Labs walks us through the list of considerations and the experience he and his co-authors had with the RFC process.
Last year we discovered a DNS vulnerability that, combined with a configuration error, can lead to massive DNS traffic surges. Since then, we've studied it carefully, carried out responsible disclosure, helped large operators as Google and Cisco in fixing their services, and submitted an Internet D…
How much of a problem are large DNS responses over UDP in the wild?
There have been growing concerns over the last few years about the excessive concentration of control over the Internet's markets and infrastructure — what is commonly referred to as Internet centralisation. In this article, Giovane Moura talks about how he and his colleagues have been measuring ce…
There is no consensus on how to choose DNS time-to-live (TTL) values for domain names. Yet, TTLs are incredibly important, given that they indirectly control how long resolvers cache records, directly influencing user experience.
New technical report evaluates DNS defenses in the wild against DDoS attacks and shows some interesting results.
DNS TTL violations is a controversial topic. It basically means a resolver overrides a TTL value provided by an authoritative server, and then serving its clients with this value. In this post, we analyse if this is happening in the wild.
The B-root operators have announced that they would enable IP anycast on 1 May 2017 [1]. In this article, we show how that change has been perceived by the RIPE Atlas probes, and if there were any transient effects of this change.
“A good thing about the IETF is that it is open and discussions are public so here is the link to the discussion inside the IETF about this article: https://mailarchive.ietf.org/arch/msg/ietf/M2vDMHuj063n5jvcUydcr0oRWy0/”
thanks for posting this, Stéphane .
“You should probably add that several DNS-implementations (embedded devices or not) ignore low TTL-values and cache for anything between several hours or even days :) This may or may not be caused by bugs, but depending on low TTL values on the general internet is not too smart.”
Yep, I mean, TTL values are in fact upper limits; resolvers however would do whatever the want. Now, there are many implementations and corner cases as you point . However, we evaluated the population of resolvers used by atlas probes (15,000 more less) and resolvers querying .nl auth servers -- that is where conclusions are based on. But I agree that some boxes would do just what they want
This is a great initiative. If it works as expected, it has the potential to cover most cloud providers. Measurements from cloud providers are , in fact, very important for user's experiences. Nowadays, many users wind up using backend systems very often hosted in big cloud providers, without being aware of it and being 1000s of km away from it. For example, you can see at [1] that 1/3 of DNS queries to .nl are actually from the US -- a ratio larger than the queries from the Netherlands. One of the reasons is that many users in the NL are using US-based cloud backends (social networking, as an example). So if works, would be great to a have probe per cloud provider, per datacenter. In this way, we can have a better understand of user' s experience when they (in)directly use these services. [1] https://stats.sidnlabs.nl/en/network.html
> I still disagree with the term: first, a resolver does not always talk with an authoritative name server, it may talk to an upstream > resolver a forwarder), and so receive a smaller TTL. There may be many "middleboxes" -- other boxes in between resolver and the client , as you pointed (just like fig 1 in [0] I am not saying the violations were performed by the local resolver. I am only claiming they were violated/changed. Now, to avoid any "cache hit" in any "middlebox" -- ie., shared cache, other resovlers, etc. -- which woudl return me a smaller TTL value -- I ensured that each probe sent a unique query -- see step 3 on section 2. So even if two probes used the same local resolver at the same time, they would have asked for diff records , in the format of $probeID.cachetest.nl > Also, all DNS implementations have an upper bound for TTLs (sometimes configurable, as with BIND and Unbound). Is it a "violation" to cap a one-month TTL (seen in the wild) to one week? "Violation" in this case is changing the value provided by the auth server, in regardless of the intention. I am not implying any judgment on the value change, only a value change. refs: [0] https://www.isi.edu/~johnh/PAPERS/Mueller17a.html
Thanks Stéphane for your feedback. I refer to TTL violations as in [1] , which is when a resolver " overrides the TTL value" . In regardless if is increased or decreases; just different from what the authoritative returns. So in this context , violation is not protocol violation, is the violation or changing the original TTL value provided by the authoritative. thanks, /gio [1] https://dl.acm.org/citation.cfm?doid=3143361.3143375
Showing 5 comment(s)