The talk presents fomr of the nic.at R&D work in the fields of Encrypted DNS. The main topics are standardization efforts (and reasoning) about EDNS(0) padding, and a cost estimation of DNS over TLS.
This talk was giving in July 2017 at JSCA, an event of the .fr ccTLD operator AFNIC:
Handy Networking Tools and How to Use ThemSneha Inguva
When I joined the networking team at DigitalOcean a few years ago, I dove into an entirely different world of software-defined networking in the data center. Virtual switches, networking protocols — these were concepts that I had encountered at the surface level before — but now I frequently found myself debugging them. With time, I came to rely on a variety of Linux networking tools for introspecting, troubleshooting, and examining network state. In this talk, I’ll share some of my favorite Linux networking tools and discuss scenarios in which they are quite helpful.
A contemporary network service heavily depends on domain name system operating normally. Yet, often issues and caveats of typical DNS setup are being overlooked. DNS (like BGP before) is expected to "just work" everywhere, however, just as BGP, this is a complex protocol and a complex solution where a lot of things could go wrong in multiple ways under different circumstances. This talk is supposed to provide some assistance both in maintaining your own DNS infrastructure and in relying on service providers doing this.
How to send DNS over anything encryptedMen and Mice
Today, nearly all DNS queries are send unencrypted. This makes DNS vulnerable to eavesdropping by someone with access to the network. The DNS-Privacy group (DPRIVE) inside the Internet Engineering Task Force (IETF), as well as people outside the IETF, are working on new transport protocols to encrypt DNS traffic between DNS clients and resolver.
* DNS over TLS (RFC 7858)
* DNS over DTLS (RFC 8094)
* DNS over HTTP(S) (ID-draft)
* DNS over QUIC (ID-draft)
* DNS over DNSCrypt (outside IETF)
* DNS over TOR (outside IETF)
In this webinar, we will explain the protocols available or discussed inside and outside the IETF, and give some example configurations on how to use this new privacy protocols today.
Hacker Halted 2014 - Why Botnet Takedowns Never Work, Unless It’s a SmackDown!EC-Council
Why Botnet Takedowns Never Work, Unless It’s a SmackDown!
If organizations are truly working to limit Internet abuse and protect end users, we need to take a more thoughtful approach to botnet takedowns – or once again bots will veer their ugly heads.
There are three main causes of ineffective takedowns:
The organizations performing botnet takedowns do so in a haphazard manner.
The organizations do not account for secondary communication methods, such as peer-to-peer or domain generation algorithms (DGA) that may be used by the malware.
The takedowns do not result in the arrest of the malware actor.
So what does a successful botnet take down actually look like? In his presentation on Botnet SmackDowns, Brian Foster, CTO of Damballa will share with attendees how to effectively takedown botnets for good. The only way botnet takedowns will have a lasting impact on end user safety is if security researchers use a comprehensive and systematic process that renders the botnet inoperable.
What Goes In Must Come Out: Egress-Assess and Data ExfiltrationCTruncer
This presentation documents how Egress-Assess can be used on assessments to simulate exfiltrating data over a variety of protocols.
Additionally, this presentation documents the addition of malware modules into Egress-Assess. The new malware modules allow users to emulate different pieces of malware families by using documented malware indicators.
Network State Awareness & Troubleshooting, by Faraz Shamim.
A presentation given at APRICOT 2016’s Network State Awareness and Troubleshooting tutorial on 25 February 2016.
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024APNIC
Ellisha Heppner, Grant Management Lead, presented an update on APNIC Foundation to the PNG DNS Forum held from 6 to 10 May, 2024 in Port Moresby, Papua New Guinea.
More Related Content
Similar to A curious case of broken dns responses - RIPE75
The talk presents fomr of the nic.at R&D work in the fields of Encrypted DNS. The main topics are standardization efforts (and reasoning) about EDNS(0) padding, and a cost estimation of DNS over TLS.
This talk was giving in July 2017 at JSCA, an event of the .fr ccTLD operator AFNIC:
Handy Networking Tools and How to Use ThemSneha Inguva
When I joined the networking team at DigitalOcean a few years ago, I dove into an entirely different world of software-defined networking in the data center. Virtual switches, networking protocols — these were concepts that I had encountered at the surface level before — but now I frequently found myself debugging them. With time, I came to rely on a variety of Linux networking tools for introspecting, troubleshooting, and examining network state. In this talk, I’ll share some of my favorite Linux networking tools and discuss scenarios in which they are quite helpful.
A contemporary network service heavily depends on domain name system operating normally. Yet, often issues and caveats of typical DNS setup are being overlooked. DNS (like BGP before) is expected to "just work" everywhere, however, just as BGP, this is a complex protocol and a complex solution where a lot of things could go wrong in multiple ways under different circumstances. This talk is supposed to provide some assistance both in maintaining your own DNS infrastructure and in relying on service providers doing this.
How to send DNS over anything encryptedMen and Mice
Today, nearly all DNS queries are send unencrypted. This makes DNS vulnerable to eavesdropping by someone with access to the network. The DNS-Privacy group (DPRIVE) inside the Internet Engineering Task Force (IETF), as well as people outside the IETF, are working on new transport protocols to encrypt DNS traffic between DNS clients and resolver.
* DNS over TLS (RFC 7858)
* DNS over DTLS (RFC 8094)
* DNS over HTTP(S) (ID-draft)
* DNS over QUIC (ID-draft)
* DNS over DNSCrypt (outside IETF)
* DNS over TOR (outside IETF)
In this webinar, we will explain the protocols available or discussed inside and outside the IETF, and give some example configurations on how to use this new privacy protocols today.
Hacker Halted 2014 - Why Botnet Takedowns Never Work, Unless It’s a SmackDown!EC-Council
Why Botnet Takedowns Never Work, Unless It’s a SmackDown!
If organizations are truly working to limit Internet abuse and protect end users, we need to take a more thoughtful approach to botnet takedowns – or once again bots will veer their ugly heads.
There are three main causes of ineffective takedowns:
The organizations performing botnet takedowns do so in a haphazard manner.
The organizations do not account for secondary communication methods, such as peer-to-peer or domain generation algorithms (DGA) that may be used by the malware.
The takedowns do not result in the arrest of the malware actor.
So what does a successful botnet take down actually look like? In his presentation on Botnet SmackDowns, Brian Foster, CTO of Damballa will share with attendees how to effectively takedown botnets for good. The only way botnet takedowns will have a lasting impact on end user safety is if security researchers use a comprehensive and systematic process that renders the botnet inoperable.
What Goes In Must Come Out: Egress-Assess and Data ExfiltrationCTruncer
This presentation documents how Egress-Assess can be used on assessments to simulate exfiltrating data over a variety of protocols.
Additionally, this presentation documents the addition of malware modules into Egress-Assess. The new malware modules allow users to emulate different pieces of malware families by using documented malware indicators.
Network State Awareness & Troubleshooting, by Faraz Shamim.
A presentation given at APRICOT 2016’s Network State Awareness and Troubleshooting tutorial on 25 February 2016.
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024APNIC
Ellisha Heppner, Grant Management Lead, presented an update on APNIC Foundation to the PNG DNS Forum held from 6 to 10 May, 2024 in Port Moresby, Papua New Guinea.
2.Cellular Networks_The final stage of connectivity is achieved by segmenting...JeyaPerumal1
A cellular network, frequently referred to as a mobile network, is a type of communication system that enables wireless communication between mobile devices. The final stage of connectivity is achieved by segmenting the comprehensive service area into several compact zones, each called a cell.
Understanding User Behavior with Google Analytics.pdfSEO Article Boost
Unlocking the full potential of Google Analytics is crucial for understanding and optimizing your website’s performance. This guide dives deep into the essential aspects of Google Analytics, from analyzing traffic sources to understanding user demographics and tracking user engagement.
Traffic Sources Analysis:
Discover where your website traffic originates. By examining the Acquisition section, you can identify whether visitors come from organic search, paid campaigns, direct visits, social media, or referral links. This knowledge helps in refining marketing strategies and optimizing resource allocation.
User Demographics Insights:
Gain a comprehensive view of your audience by exploring demographic data in the Audience section. Understand age, gender, and interests to tailor your marketing strategies effectively. Leverage this information to create personalized content and improve user engagement and conversion rates.
Tracking User Engagement:
Learn how to measure user interaction with your site through key metrics like bounce rate, average session duration, and pages per session. Enhance user experience by analyzing engagement metrics and implementing strategies to keep visitors engaged.
Conversion Rate Optimization:
Understand the importance of conversion rates and how to track them using Google Analytics. Set up Goals, analyze conversion funnels, segment your audience, and employ A/B testing to optimize your website for higher conversions. Utilize ecommerce tracking and multi-channel funnels for a detailed view of your sales performance and marketing channel contributions.
Custom Reports and Dashboards:
Create custom reports and dashboards to visualize and interpret data relevant to your business goals. Use advanced filters, segments, and visualization options to gain deeper insights. Incorporate custom dimensions and metrics for tailored data analysis. Integrate external data sources to enrich your analytics and make well-informed decisions.
This guide is designed to help you harness the power of Google Analytics for making data-driven decisions that enhance website performance and achieve your digital marketing objectives. Whether you are looking to improve SEO, refine your social media strategy, or boost conversion rates, understanding and utilizing Google Analytics is essential for your success.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
Italy Agriculture Equipment Market Outlook to 2027harveenkaur52
Agriculture and Animal Care
Ken Research has an expertise in Agriculture and Animal Care sector and offer vast collection of information related to all major aspects such as Agriculture equipment, Crop Protection, Seed, Agriculture Chemical, Fertilizers, Protected Cultivators, Palm Oil, Hybrid Seed, Animal Feed additives and many more.
Our continuous study and findings in agriculture sector provide better insights to companies dealing with related product and services, government and agriculture associations, researchers and students to well understand the present and expected scenario.
Our Animal care category provides solutions on Animal Healthcare and related products and services, including, animal feed additives, vaccination
1. A curious case of broken
DNS responses
Babak Farrokhi
RIPE 75
2. About me
● Unix SA (FreeBSD, Solaris, Linux) since 1996
● IP Networking since 1997
● FreeBSD Ports Team since 2004
● Enthusiastic coder
@farrokhi
3. Prologue
● When it comes to network, I always have trust issues
● Most people ignore those strange network behaviors
● Only a few people take the red pill and go down the rabbit
hole...
4. Observation
● Outgoing SMTP fails due to MX lookup failures
○ only certain domains (e.g. twitter.com)
● Local resolver returns “incorrect” response
● Public Resolver (e.g. Google) also returned incorrect
response
● I needed to look deeper into this
6. Strange responses from public resolvers
This is not what I expected to get from a public resolver:
% dig +short -t A twitter.com @8.8.8.8
10.10.34.34
% dig +short -t A ripe.net @8.8.8.8
193.0.6.139
% dig -t MX twitter.com @8.8.8.8
;; Got bad packet: bad label type
45 bytes
40 10 81 80 00 01 00 01 00 00 00 00 07 74 77 69 @............twi
74 74 65 72 03 63 6f 6d 00 00 0c 00 01 c0 0c 00 tter.com........
0c 00 01 00 00 03 79 00 03 41 41 41 00 ......y..AAA.
7. Need to take a closer look
Not obvious at first glance, but time delta is strange...
% tcpdump -ttt -c2 -nqr ripe.pcap
reading from PCAP-NG file ripe.pcap
00:00:00.000000 IP 192.168.0.132.53425 > 8.8.8.8.53: UDP, length 27
00:00:00.138933 IP 8.8.8.8.53 > 192.168.0.132.53425: UDP, length 75
% tcpdump -ttt -c2 -nqr twitter.pcap
reading from PCAP-NG file twitter.pcap
00:00:00.000000 IP 192.168.0.132.58418 > 8.8.8.8.53: UDP, length 29
00:00:00.028077 IP 8.8.8.8.53 > 192.168.0.132.58418: UDP, length 45
8. dnsping - A new tool is born
● Started as a humble Python script to solve my own problem
● Not intended to re-invent the wheel
● Similar user experience as the legacy PING
% ./dnsping.py -s 8.8.8.8 -c3 ripe.net
dnsping.py DNS: 8.8.8.8:53, hostname: ripe.net, rdatatype: A
32 bytes from 8.8.8.8: seq=0 time=200.371 ms
32 bytes from 8.8.8.8: seq=1 time=217.320 ms
32 bytes from 8.8.8.8: seq=2 time=236.644 ms
--- 8.8.8.8 dnsping statistics ---
3 requests transmitted, 3 responses received, 0% lost
min=200.371 ms, avg=218.112 ms, max=236.644 ms, stddev=18.149 ms
9. ICMP vs DNS Response Times
% ping -q -c10 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 124.237/155.044/227.499/31.464 ms
% ./dnsping.py -q -s 8.8.8.8 -c3 twitter.com
dnsping.py DNS: 8.8.8.8:53, hostname: twitter.com, rdatatype: A
--- 8.8.8.8 dnsping statistics ---
3 requests transmitted, 3 responses received, 0% lost
min=12.934 ms, avg=21.355 ms, max=29.425 ms, stddev=8.251 ms
10. First anomaly
● Different domain names being treated differently
● A rogue name server impersonating as Google Resolver
● The rogue name server is close to me (given response
times)
● Where is it? And how can I find out?
11. dnstraceroute: Traceroute tool for DNS protocol
● Similar to legacy traceroute, but for DNS protocol
● Send out actual DNS queries and expect a response
● Using TTL trick to map the journey
● Could not use legacy traceroute with UDP probes
○ The traffic redirection is based on DNS “payload”
12. Real vs Rogue DNS Servers
% ./dnstraceroute.py -s 8.8.8.8 ripe.net
dnstraceroute.py DNS: 8.8.8.8:53, hostname: ripe.net,
rdatatype: A
1 192.168.0.1 (192.168.0.1) 3.912 ms
2 *
3 192.168.10.105 (192.168.10.105) 15.792 ms
4 172.17.2.1 (172.17.2.1) 17.063 ms
5 172.17.2.9 (172.17.2.9) 11.245 ms
6 172.19.18.5 (172.19.18.5) 24.862 ms
7 172.19.17.2 (172.19.17.2) 18.972 ms
8 10.201.177.41 (10.201.177.41) 13.261 ms
9 10.10.53.190 (10.10.53.190) 14.240 ms
10 185.100.209.117 (185.100.209.117) 176.592 ms
11 *
12 de-cix.fra.google.com (80.81.192.108) 152.757 ms
13 108.170.251.193 (108.170.251.193) 90.347 ms
14 google-public-dns-a.google.com (8.8.8.8) 185.401 ms
% ./dnstraceroute.py -s 8.8.8.8 twitter.com
dnstraceroute.py DNS: 8.8.8.8:53, hostname:
twitter.com, rdatatype: A
1 192.168.0.1 (192.168.0.1) 3.160 ms
2 *
3 192.168.10.105 (192.168.10.105) 5.985 ms
4 172.17.2.1 (172.17.2.1) 8.535 ms
5 172.17.2.9 (172.17.2.9) 20.617 ms
6 172.19.18.5 (172.19.18.5) 7.823 ms
7 *
8 *
9 google-public-dns-a.google.com (8.8.8.8) 19.557 ms
13. Back to the case of broken MX
● Rogue nameserver also returns “broken” responses
● Only to certain type of queries (e.g. MX)
% dig -t MX twitter.com @8.8.8.8
;; Got bad packet: bad label type
45 bytes
40 10 81 80 00 01 00 01 00 00 00 00 07 74 77 69 @............twi
74 74 65 72 03 63 6f 6d 00 00 0c 00 01 c0 0c 00 tter.com........
0c 00 01 00 00 03 79 00 03 41 41 41 00 ......y..AAA.
14. Looking at packets again...
● Response to MX request is malformed
○ Server responded with PTR response
○ RDLENGTH is 3 but RDATA field contains 4 bytes
■ Additional byte was always NULL
■ Seems like a bug in code
● Queried top 10,000 domain names [1], received 139
broken responses [2]
15. Uncovering the rouge resolver address
● Query TXT record from maxmind.test-ipv6.com
● It tells you the public address of your resolver
○ The address should belong to Google (AS15169)
○ Anything else means MITM
● Using RIPE Atlas to see if this is a regular practice
% dig +short -t TXT maxmind.test-ipv6.com @8.8.4.4
"ip='74.125.74.14' as='15169' isp='Google' country='FI'"
16. Is it just me? Let's ask RIPE Atlas
● 500 Probes worldwide - 484 Replied (DNS/UDP/IPv4)
○ 475 Good (Req. from Google address space) ~98%
○ 9 Bad (Req. from non-Google address space) ~2%
● Same 500 probes - 484 Replied (DNS/TCP/IPv4)
○ 479 Good ~99%
○ 5 Bad ~1%
18. What is the motivation?
There are mainly two reasons:
1. Privacy protection (The Good)
○ Prevent sending request to use have your end-point IP
address as its source address
○ Filter out malwares looking for their C&C
2. DNS based service redirection (The Evil)
○ Restrict your access
○ Redirect your traffic
19. Countermeasures
● Force local resolver to use TCP
● DNSCrypt (dnscrypt.org)
○ OpenDNS supports it, desktop clients available
● DNS over TLS/DTLS (RFC 7858 and 8094)
○ DNS Privacy Project (dnsprivacy.org) offers tutorials, tools,
recommendations and test servers
● DNSSEC
○ From top 100 domain names only 2 of them are signed [3]
○ What if the rogue nameserver does not validate DNSSEC?
20. Final words
● Don’t trust a public DNS resolver, use your own
○ There ain't no such thing as a free lunch (TANSTAAFL)
○ Stub resolvers are easy to setup and use (e.g. Stubby)
● Don’t trust your upstream, encrypt as much as possible
○ DNS contains important information
○ As per RFC7258: “Pervasive Monitoring Is an Attack”
21. Tools of the trade
● dnsping, dnstraceroute and dnseval are part of “dnsdiag
toolkit” on GitHub [4]
○ Looking for feedback and ideas from community
● Combining with other tools (e.g. RIPE Atlas) to perform
more complex behavior analysis
● Suggestion: dnstraceroute in RIPE Atlas probes?