Podcasts about domain name system dns

The Domain Name System (DNS) keeps the Internet running. On today’s N Is For Networking podcast, we talk about how DNS transforms human-readable host names into IP addresses so that Internet traffic can be sent to the right place. We talk about root name servers, Top Level Domains (TLDs), and other elements of the DNS... Read more »

The Domain Name System (DNS) keeps the Internet running. On today’s N Is For Networking podcast, we talk about how DNS transforms human-readable host names into IP addresses so that Internet traffic can be sent to the right place. We talk about root name servers, Top Level Domains (TLDs), and other elements of the DNS... Read more »

In his first episode of PING for 2025, APNIC's Chief Scientist, Geoff Huston returns to the Domain Name System (DNS) and explores the many faces of name servers behind domains. Up at the root, (the very top of the namespace, where all top-level domains like .gov or .au or .com are defined to exist) there is a well established principle of 13 root nameservers. Does this mean only 13 hosts worldwide service this space? Nothing could be farther from the truth! literally thousands of hosts act as one of those 13 root server labels, in a highly distributed worldwide mesh known as "anycast" which works through BGP routing. The thing is, exactly how the number of nameservers for any given domain is chosen, and how resolvers (the querying side of the DNS, the things which ask questions of authoritative nameservers) decide which one of those servers to use isn't as well defined as you might think. The packet sizes, the order of data in the packet, how it's encoded is all very well defined, but "which one should I use from now on, to answer this kind of question" is really not well defined at all. Geoff has been using the Labs measurement system to test behaviour here, and looking at basic numbers for the delegated domains at the root. The number of servers he sees, their diversity, the nature of their deployment technology in routing is quite variable. But even more interestingly, the diversity of "which one gets used" on the resolver side suggests some very old, out of date and over-simplistic methods are still being used almost everywhere, to decide what to do.

Episode 204 Join us as we Zoom in to the biggest crowd we have ever seen.Fancy a cycle around the neighborhood with the kids on your hot new bicycle? Read our update first!There's a new copilot that could make a huge difference to your open source project and a huge new fine for one European mobile phone company (in the US).Then, a story about a firm that could've had the best security in the world, but it wouldn't have mattered because they published their own passwords on-line.We get a solemn reminder that no matter how rich and how smart, there is always an element of risk in anything you do.From Taiwan, a new Domain Name System (DNS) backdoor that is exponentially more clever.And we finish by crashing a plane tracker that was leaking user data ….for three years.We zoom 'round and 'round this big world of ours delivering the best in IT Privacy and Security.So settle in and let's go! Find the full transcript to this podcast here.

During Black Hat USA 2024 in Las Vegas, Sean Martin engages in a Brand Story conversation with TK Keanini from DNSFilter to explore the pivotal role DNSFilter plays in safeguarding networks around the world. DNSFilter operates by leveraging the Domain Name System (DNS), an essential component of the internet. As TK Keanini shares, the company's primary mission is to filter out malicious traffic and allow legitimate traffic to pass through, thereby providing an effective layer of security that is both accessible and user-friendly.The applicability of DNSFilter spans globally, reflecting the nature of cyber threats, which are not confined by geographic borders. One critical aspect discussed is DNSFilter's ability to manage approximately 130 billion DNS requests daily, blocking between three to four billion potentially harmful requests. This impressive scale underscores the importance of DNSFilter in preventing cyberattacks and protecting users from inadvertently accessing malicious sites.From coffee shops to large enterprises, the relevance and ease of deploying DNSFilter stand out. For businesses, the practical uses of DNSFilter are numerous.Keanini explains that the technology is effortless to set up and can be integrated directly into various levels of IT infrastructure, including Wi-Fi routers in coffee shops and public Wi-Fi in retail settings. This straightforward setup enables even those with minimal technical expertise to implement robust cybersecurity measures easily.The conversation also highlights DNSFilter's effectiveness in addressing global issues, such as Child Sexual Abuse Material (CSAM), reinforcing the company's commitment to making the internet safer for everyone. The firm's blocking capabilities are not limited to phishing and ransomware; they extend to other harmful content categories, ensuring comprehensive protection.Moreover, for Chief Information Security Officers (CISOs) and organizations with established cybersecurity programs, DNSFilter offers an invaluable addition to their security suite. With DNSFilter, policies can be set with a single click, streamlining the process for schools, businesses, and managed service providers alike. Keanini points out that this level of usability ensures that even those without extensive cybersecurity experience can effectively manage and implement necessary protections.Additionally, Keanini emphasizes the importance of DNSFilter's role in protecting everyday users on public Wi-Fi networks and its affordability for public-use scenarios. DNSFilter's technology integrates smoothly into existing security frameworks, providing peace of mind to users and IT administrators that their networks are secure. For individuals and organizations looking to enhance their online security, DNSFilter presents a compelling solution. With its easy setup, global reach, and comprehensive protection against a wide range of cyber threats, DNSFilter stands as a vital tool in the arsenal of modern cybersecurity solutions.Learn more about DNSFilter: https://itspm.ag/dnsfilter-1g0fNote: This story contains promotional content. Learn more.Guest: TK Keanini, CTO, DNSFilter [@DNSFilter]On LinkedIn | https://www.linkedin.com/in/tkkeaninipub/ResourcesLearn more and catch more stories from DNSFilter: https://www.itspmagazine.com/directory/dnsfilterView all of our Black Hat USA  2024 coverage: https://www.itspmagazine.com/black-hat-usa-2024-hacker-summer-camp-2024-event-coverage-in-las-vegasAre you interested in telling your story?https://www.itspmagazine.com/telling-your-story

During Black Hat USA 2024 in Las Vegas, Sean Martin engages in a Brand Story conversation with TK Keanini from DNSFilter to explore the pivotal role DNSFilter plays in safeguarding networks around the world. DNSFilter operates by leveraging the Domain Name System (DNS), an essential component of the internet. As TK Keanini shares, the company's primary mission is to filter out malicious traffic and allow legitimate traffic to pass through, thereby providing an effective layer of security that is both accessible and user-friendly.The applicability of DNSFilter spans globally, reflecting the nature of cyber threats, which are not confined by geographic borders. One critical aspect discussed is DNSFilter's ability to manage approximately 130 billion DNS requests daily, blocking between three to four billion potentially harmful requests. This impressive scale underscores the importance of DNSFilter in preventing cyberattacks and protecting users from inadvertently accessing malicious sites.From coffee shops to large enterprises, the relevance and ease of deploying DNSFilter stand out. For businesses, the practical uses of DNSFilter are numerous.Keanini explains that the technology is effortless to set up and can be integrated directly into various levels of IT infrastructure, including Wi-Fi routers in coffee shops and public Wi-Fi in retail settings. This straightforward setup enables even those with minimal technical expertise to implement robust cybersecurity measures easily.The conversation also highlights DNSFilter's effectiveness in addressing global issues, such as Child Sexual Abuse Material (CSAM), reinforcing the company's commitment to making the internet safer for everyone. The firm's blocking capabilities are not limited to phishing and ransomware; they extend to other harmful content categories, ensuring comprehensive protection.Moreover, for Chief Information Security Officers (CISOs) and organizations with established cybersecurity programs, DNSFilter offers an invaluable addition to their security suite. With DNSFilter, policies can be set with a single click, streamlining the process for schools, businesses, and managed service providers alike. Keanini points out that this level of usability ensures that even those without extensive cybersecurity experience can effectively manage and implement necessary protections.Additionally, Keanini emphasizes the importance of DNSFilter's role in protecting everyday users on public Wi-Fi networks and its affordability for public-use scenarios. DNSFilter's technology integrates smoothly into existing security frameworks, providing peace of mind to users and IT administrators that their networks are secure. For individuals and organizations looking to enhance their online security, DNSFilter presents a compelling solution. With its easy setup, global reach, and comprehensive protection against a wide range of cyber threats, DNSFilter stands as a vital tool in the arsenal of modern cybersecurity solutions.Learn more about DNSFilter: https://itspm.ag/dnsfilter-1g0fNote: This story contains promotional content. Learn more.Guest: TK Keanini, CTO, DNSFilter [@DNSFilter]On LinkedIn | https://www.linkedin.com/in/tkkeaninipub/ResourcesLearn more and catch more stories from DNSFilter: https://www.itspmagazine.com/directory/dnsfilterView all of our Black Hat USA  2024 coverage: https://www.itspmagazine.com/black-hat-usa-2024-hacker-summer-camp-2024-event-coverage-in-las-vegasAre you interested in telling your story?https://www.itspmagazine.com/telling-your-story

Send us a Text Message.How does the invisible architecture of the internet keep everything running smoothly? Prepare to have your mind blown as we unravel the mysteries of the Domain Name System (DNS) in this episode of Learn System Design. We'll guide you through the intricate process of how your browser finds the correct IP address for a domain name, likening DNS to an enormous, sophisticated key-value database. Discover the essential components that make DNS work seamlessly, from DNS servers and resource records to caching mechanisms. We break down the DNS hierarchy, explaining the pivotal roles of recursive resolvers, root name servers, and top-level domain servers.But that's not all—we're also diving deep into the world of service discovery patterns. Which is better: client-side or server-side discovery? We'll weigh the pros and cons of each, spotlighting real-world examples like Netflix's Eureka and AWS Elastic Load Balancer. Learn why a service registry is crucial for maintaining an updated list of services and how heartbeat checks fit into this ecosystem. Finally, we explore three popular service discovery methods—DNS-based, Apache Zookeeper, and sidecar services—giving you an in-depth look at their benefits and limitations. This episode is your ultimate guide to building robust and efficient systems, so tune in and elevate your system design knowledge!Learn more about the different types of DNS Records (Zone files)Support the Show.Dedicated to the memory of Crystal Rose.Email me at LearnSystemDesignPod@gmail.comJoin the free Discord Consider supporting us on PatreonSpecial thanks to Aimless Orbiter for the wonderful music.Please consider giving us a rating on ITunes or wherever you listen to new episodes.

In Episode 211 of TSARP, we've got some exciting news! The Tesla Cybertruck is arriving to Tesla dealers this Thursday (11/30/23) Ready to take your coding skills to the next level? The KidOYO Passport is your all-access pass to an array of coding courses, interactive editors, and exhilarating events like game jams and hackathons. Start your coding adventure today by signing up at https://kidoyo.com/events. Don't miss a beat! Stay connected by tuning into future episodes of the TSARP Podcast and following us on Twitter at https://linktr.ee/tsarp. Chapters: 00:00 - Introduction and Hosts Greeting 00:24 - Discussion on Tesla's Cybertruck Shipping 01:13 - Visual Presentation of the Cybertruck 03:00 - Sad News: Passing of Charlie Munger 06:00 - Tech Fun Fact: Mariner 4 Spacecraft 08:04 - Participating in NASA's Europa Clipper Mission 13:56 - Speedrun Segment: Fortnite and Other Tech News 16:06 - Gimkit Platform Down Due to DNS Issue 18:03 - Discussion on Domain Name System (DNS) 23:00 - Topic Speedrun Sponsored Segment 24:36 - Transition to Playing Games 25:34 - Playing Code Clash Games 29:37 - Reviewing Sam's Projects 31:28 - Exploring Steven's Projects 34:17 - Playing Steven's Python Game 36:38 - Closing Remarks and Tease for Next Episode 38:25 - Final Thoughts and Gratitude Sharing

IntroductionIn this episode, we'll be discussing domain name registrars. We'll talk about what they are, how they work, and how to choose the best one for your needs.What is a domain name registrar?A domain name registrar is a company that registers and sells domain names. When you buy a domain name from a registrar, you're essentially renting it for a certain amount of time. The registrar is responsible for keeping track of who owns the domain name and making sure that it's properly pointed to your website.How do domain name registrars work?When you buy a domain name from a registrar, they'll add your name and contact information to a database called the Domain Name System (DNS). The DNS is a big list of all the domain names in the world and their corresponding IP addresses. When someone types your domain name into their browser, their computer will query the DNS to find the IP address of your website.How to choose the best domain name registrar for youThere are a few factors to consider when choosing a domain name registrar. These include:Price: Domain name registrars typically charge different prices for domain names. It's important to compare prices before you buy a domain name.Features: Different registrars offer different features, such as free domain privacy, email forwarding, and DNSSEC. Make sure to choose a registrar that offers the features you need.Customer support: If you have any problems with your domain name, you'll need to contact the registrar's customer support team. Make sure to choose a registrar with a good reputation for customer support.Popular domain name registrarsHere are some of the most popular domain name registrars:Domain.comNamecheapBluehostGoogle DomainsGoDaddyHostGatorName.comNameSiloDynadotDreamHosthttps://url.amit.so/bio

The internet has a significant role in our daily lives, and also, this is a place where we are concerned about security. We merely depend on website information that users can access through a Domain Name System (DNS). This DNS can be spoofed by hackers that can be redirected to fraudulent websites resulting in malware attacks and data loss. In this detailed blog, we will discuss DNS spoofing, how it works, methods of DNS spoofing, tools used, and tips to avoid DNS spoofing. Read More: All About DNS Spoofing

Antariksh Matters: Shattering Space Record Myths— Pranav R SatyanathEarlier this week, a record was broken in the shadowy world of military space tech. At least, that's what some of the headlines make you believe. The secretive X-37B Orbital Test Vehicle (OTV) uncrewed spaceplane, operated by the US Space Force, landed at the NASA Kennedy Space Center on November 12th after spending 908 days in orbit. It broke the previous orbital record (780 days) by a large margin. The spaceplane, which is built by Boeing, has been in operation since 2010. Its mission and purpose are largely unknown, building some sort of a myth around this mini-Space Shuttle-looking vehicle.Let's take a step back. From all the open-source images available, we know that the X-37B has a single liquid-fuelled engine built by Aerojet and powered by storable propellants. This means it can stay in orbit by increasing its altitude. So, one can say that spaceplanes are not very different from regular satellites, which operate for years and decades in orbit. Now compare those years and decades to 908 days. Not much, right? Well, yes. So long as the spaceplane can maintain orbital speed, it can stay in orbit as long as its operators wish. Although we don't know much about the X-37B's true purpose, we know some meta details that give clues as to what the purpose might be. The programme that gave birth to the X-37B isn't a secret. Back in the early 1990s, people in the US government got pretty worried about the costs of operating the Space Shuttle. It was reusable for sure, but it was a slow and painstaking process to get the vehicle back to space. So, the US Congress told NASA to go and look at other alternatives. The result was the Access to Space study, which outlined faster, better, cheaper and smaller alternatives to the Suttle. After pondering their heads over what to test, NASA began to fund a handful of companies to research and develop reusable spaceplanes, including Single-Stage To Orbit (SSTO) tech, which is considered the pinnacle of rocketry.Chief among these experimental spaceplanes included Lockheed Martin's X-33 and Orbital Science's X-34 reusable launch vehicles, along with Boeing's X-37 experimental space manoeuvring vehicle. By 1999, NASA saw the funds dry up and no progress to show. The US Air Force (USAF) was ready to take up the X-34 and the X-37 programmes. The X-34 programme got cancelled, and the X-37 was transferred to the Defense Advanced Research Projects Agency (DARPA). Two years later, the X-37B was in the hands of the USAF.From what we know, we can draw out two hypotheses:* The X-37B is a highly manoeuvrable vehicle used to inspect suspicious activities and objects in space. * The X-37B is a test vehicle for the US Space Force (and Air Force) which allows them to test hypersonic re-entry, autonomous capabilities and perhaps, deployment of small payloads.A part of the second hypothesis is already confirmed. Astronomer and space watcher Jonathan McDowell reported that the X-37B launched a subsatellite named the FalconSAT-t8, an experimental payload developed by the Air Force Academy. The second hypothesis is less likely to be true, as small satellites can perform a far better (and less suspicious) job of inspecting suspicious activities and objects.Like the US, the Chinese also have a handful of spaceplane projects. It will not be surprising that these vehicles will have both civilian and military uses. India is also testing a version of its spaceplane called the Reusable Launch Vehicle-Technology Demonstrator (RLV-TD). Spaceplanes are interesting. But we must not get carried away by spooky headlines.Comments on the Draft Telecommunications Bill, 2022— Satya Sahu and Gayathri PotiThe draft Telecommunications Bill, 2022 will do more to prohibit Digital India's growth story rather than facilitate it. We outline some of its most glaring issues:Definitional Over-breadth, Legislative Conflict and Procedural Lacunae* Explanatory Note to the Bill in para.51 reassures that provisions concerning internet shutdowns recognize citizens' rights; there is no enumeration of this safeguard in the concerned clause nor mechanisms for judicial oversight or review panels to record the legality of suspension orders à la the Telecom Suspension Rules, 2017.* The Union Government recently withdrew the Personal Data Protection Bill, 2021. In the absence of a data protection regime and an independent Data Protection Authority vested with powers to implement safeguards on the access and use of personal data by public authorities in line with the principles laid out in Puttaswamy and Shreya Singhal. , Clause 24(2)(b) contributes to the increasingly fragmented data protection framework in India, alongside the IT Act, 2000, SEBI Data Sharing Policy, 2019, Payments and Settlements Act, 2008 etc. Regulatory uncertainty and compliance costs within this framework become increasingly difficult due to the wide gamut of entities subject to the definition of "Telecommunication services" under Clause 2(2). The increased cost of compliance with implementing KYC norms and mandatory licensing regimes will result in extremely high barriers to entry for players in the OTT market. It will ensure that only market players with significant resources to meet these obligations can afford to remain in it, amplifying concerns about stifled innovation and competition in this oligopolistic sector.* Subjecting OTT platforms to DoT jurisdiction creates regulatory overlap with MeitY's powers, creating potentially conflicting laws, duplication of efforts by regulators and market players alike, ownership of implementation measures, and increasing costs of conducting business.* OTT platforms like real-time messaging services deploy E2E encryption. Currently, access to encrypted communication is governed by the 2021 Intermediary Guidelines and Digital Media Ethics Code released by MeitY. Under this, significant social media intermediaries are only expected to enable the identification of the first originator of the information. The rules deliberately refrain from mandating access to the contents of the communication (especially since the 2015 draft rules that insisted on making available the plaintext of communications was met with heavy criticism), but Clause 24 empowers the Government to gain access to the contents of the communication as well. This conflicts with the 2021 Code and further aggravates the issue of regulatory overlap. The provision implicitly requires OTT platforms to create encryption backdoors and inevitably undermines Constitutional protection for free speech afforded by encryption.* The territorial applicability of the provisions of the Bill has not been described unlike in the Telegraph Act, 1885, and the IT Act, 2000, which circumscribe their application in terms of geography and cyber attribution. The telecom and OTT sectors depend on cross-border interconnectivity and rely on internationally administered infrastructure like satellites, marine fibre-optic cable networks, etc. It is necessary to foresee and describe the territorial limits of domestic law to avoid international conflict of laws to maintain market confidence and decrease legal costs and instances of interruption in critical services.* Clause 46 (k) of the Bill dilutes TRAI's standing to requisition information from the Government and provide recommendations before awarding licenses. Deleting the non-obstante clause and provisos to S.11 (1) of the TRAI Act eliminates TRAI's role in ensuring a level playing field for TSPs and fair and non-discriminatory treatment by the Government. Vesting TRAI with the power to investigate predatory pricing exacerbates existing overlap between the mandates of TRAI and CCI, increasing possibility of regulatory arbitrage. * Clause 24(1) vests the Central Government with the power to take temporary possession of telecommunication services, networks, and infrastructure, in the occurrence of any public emergency or in the interest of public safety. Clause 24(4) makes the exercise of this power concomitant with the duration of a public emergency or occasion. The Bill, however, does not provide any procedure for Government action nor define the terms' public safety' and 'public emergency', undermining the temporary nature of this power, inviting constitutional scrutiny and low investor confidence.Insufficient Justifications for Overarching Policy * OTT platforms should be permitted to continue operating under the existing framework without any regulatory intervention until the ITU and similar foreign jurisdictions conclusively determine the regulation of such platforms. TRAI's 2020 recommendations propose no deviation from this approach, especially since there has been limited global progress concerning OTT regulation.* Compliance with KYC norms is mandated for the issuance of SIM Cards and broadband connections; extending this requirement for accessing OTT communication services is unwarranted. The rigours associated with KYC rules are reserved for tightly regulated sectors like banking, where identity verification systems combat the incidence of high-risk pernicious activities. Mandating adherence to the KYC process for creating an account on an IM/e-mail/video telephony platform is not only disproportionate but is likely to dissuade users from accessing critical services. In particular, KYC formalities will deter consumers from testing newer platforms which could result in market stagnation.* Clause 32 envisages framing regulatory sandboxes to enable innovation and technological development in the sector. However, it allows access to regulatory sandboxes only as part of the terms and conditions under its new licensing regime defeating the intent of a regulatory sandbox. Providing access to this environment only upon the award of a license raises the costs of introducing new technology in a fixed-capital-intensive sector like telecom and entrenches the market power of already dominant entities who can bear this cost. The extent and nature of the usage of new technology cannot always be preempted in the terms of a license at the time of licensing. This creates the future burden of bearing opportunity costs of not being able to leverage its own technology in new ways on the licensee, leading to avoidable legal costs and ad hoc renegotiation.The authors are students of Takshashila's GCPP (Technology & Policy) Programme.Matsyanyaaya: Splinternet Conviction?— Bharath ReddyWe often hear predictions about a splinter-net or a bifurcated Internet. What does this mean? And what are the incentives at play other than the obvious state control and censorship?To get an idea of how the Internet could split and what it means, a good example would be Runet - the Russian national segment of the Internet. Russian interventions to create an independent national Internet range from state censorship to mandating ISPs to use national Domain Name System (DNS) servers (where website names are translated to addresses). There are also forces from outside Russia incentivising the split as well. During the initial phase of the Russia-Ukraine conflict, there were appeals by Ukraine to remove Russian domains from DNS servers which would cut them off from the rest of the Internet. This request was rejected as it could destroy trust in a global internet if the DNS does not remain neutral. However, requests by Ukraine to certificate authorities that issue SSL and TLS certificates for websites have been more successful, creating barriers in the process. Lastly, the hardware sanctions and market exits following the conflict could potentially lead to a split in internet standards.As you might know, the Internet is based on communication protocols which enable different devices to speak a common language and communicate with each other. Broadly, these protocols can be classified under - content, logic and infrastructure layers. While censorship at the content layer is quite common, a fork in the lower logic and infrastructure layers could have serious ramifications. Network effects, protocol politics and geopolitics, come together here. The largest networks have incentives to refuse to be interoperable with competitors. In the current nature of the Internet, the US and its allies wield power to cut off competitors from critical chokepoints. This power has been exercised to an extent during the recent sanctions against China and Russia. The threat of such actions creates incentives for bifurcated supply chains and in this world of bifurcated supply chains there would be takers for China's vision of national internet sovereignty. In such a scenario, future network protocols such as New IP being developed by Huawei could become more widespread. The intelligence built into the protocols at the logic and infrastructure layers could enable more surveillance and control by the ISPs and the State.The concerns around the splitting of the Internet is thus a complex interplay between technology, geopolitics, and the relation between the State and the individual.The report titled “One, Two, or Two Hundred Internets” by the Center for Security Studies (CSS), ETH Zürich is an exciting read that covers this subject in detail. As the author hopes, it helps enable informed discussion and decision-making on splitting the Internet.Our Reading Menu[Opinion] Road Ahead for UPI: Free Public Infrastructure or Yet Another Payment Mechanism? by Rohan Pai and Mihir Mahajan.[Chapter] Gene Editing and the Need to Reevaluate Bioweapons by Shambhavi Naik.[Book] Cellular: An Economic and Business History of the International Mobile-Phone Industry by Daniel D. Garcia-Swartz and Martin Campbell-Kelly. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit hightechir.substack.com

Rediscovering a decades-old cybersecurity protocol

Paul Vixie grew up in San Francisco. He dropped out of high school in 1980. He worked on the first Internet gateways at DEC and, from there, started the Internet Software Consortium (ISC), establishing Internet protocols, particularly the Domain Name System (DNS). Today, Vixie is one of the few dozen in the technology world with the title "distinguished engineer," working at Amazon Web Services as vice president of security, where he believes he can make the Internet a more safe place. As safe as before the Internet emerged. "I am worried about how much less safe we all are in the Internet era than we were before," Vixie said in an interview at the Open Source Summit in Dublin earlier this month for The New Stack Makers podcast. "And everything is connected, and very little is understood. And so, my mission for the last 20 years has been to restore human safety to pre-internet levels. And doing that at scale is quite the challenge. It'll take me a lifetime." So why join AWS? He spent decades establishing the ISC. He started a company called Farsight, which came out of ISC. He sold Farsight in November of last year when conversations began with AWS. Vixie thought about his mission to better restore human safety to pre-internet levels when AWS asked a question that changed the conversation and led him to his new role. "They asked me, what is now in retrospect, an obvious question, 'AWS hosts, probably the largest share of the digital economy that you're trying to protect," Vixie said. "Don't you think you can complete your mission by working to help secure AWS?' "The answer is yes. In fact, I feel like I'm going to get more traction now that I can focus on strategy and technology and not also operate a company on the side. And so it was a very good win for me, and I hope for them." Interviewing Vixie is such an honor. It's people like Paul who made so much possible for anyone who uses the Internet. Just think of that for a minute -- anyone who uses the Internet have people like Paul to thank. Thanks Paul -- you are a hero to many. Here's to your next run at AWS.    

DNS cache poisoning, also known as DNS spoofing, is a type of attack that diverts Internet traffic away from real servers and towards counterfeit ones by exploiting the Domain Name System (DNS) flaws. DNS poisoning is particularly harmful since it can propagate from DNS server to DNS server. #dns #dnscache #infosectrain ✅Our Official Website - https://www.infosectrain.com/ ✅For more details or free demo with out expert write into us at sales@infosectrain.com or call us at IND: 1800-843-7890 / US: +1 657-722-11127 / UK : +44 7451 208413 Subscribe to our channel to get video updates. Hit the subscribe button above. Facebook: https://www.facebook.com/Infosectrain/ Twitter: https://twitter.com/Infosec_Train LinkedIn: https://www.linkedin.com/company/infosec-train/ Instagram: https://www.instagram.com/infosectrain/ Telegram: https://t.me/infosectrains

नमस्ते दोस्तों! The Ranveer Show हिंदी के 87th Episode में आप सभी का स्वागत है। आज के Episode में हमारे साथ जुड़ चुके हैं Saket Modi जो एक बेहतरीन Entrepreneur, और Safe Security के Co-Founder और CEO हैं जो एक Cybersecurity & Digital Business Risk Quantification Company है। Cyber World और Cyber Hacking के बारे में Saket का Knowledge काफी ज़्यादा सराहनीय है। इस पॉडकास्ट में हम बात करेंगे ढ़ेर सारी बातें Dark Web, Other Side Of Internet, Crimes, Red Room और Internet के खतरे के बारे में। साथ ही साथ हम Discuss करेंगे Dark Web Horror Stories, Domain Name System (DNS), IP Address कैसे पता लगाए, डार्क वेब कैसे Use किया जाता है, Banned Books In India कैसे पढ़ें, Dark Web को Fund कौन करता है और Tor Browser का इस्तेमाल कैसे करे के बारे में और भी ढ़ेर सारी बातें। मैं आशा करता हूँ कि ये Video आप सभी Viewers को पसंद आएगा। खास तौर पर उन सभी को जो Technology, Coding और Hacking जैसे Topics में Interest रखते हैं। Cyber Security, How To Be Secured Online, Government का Dark Web पर Presence, Cyber Warfare और IP Address Masking जैसी चीज़ों के बारे में हम Discuss करेंगे इस Hindi Podcast में सिर्फ और सिर्फ आपके Favourite BeerBiceps Hindi Channel Ranveer Allahbadia पर।

Stai ascoltando un estratto gratuito di Ninja PRO, la selezione quotidiana di notizie per i professionisti del digital business. Con Ninja PRO puoi avere ogni giorno marketing insight, social media update, tech news, business events e una selezione di articoli di approfondimento dagli esperti della Redazione Ninja. Vai su www.ninja.it/ninjapro per abbonarti al servizio.L'Ucraina spinge per scollegare la Russia da Internet. Secondo un'email visionata da Rolling Stone, la richiesta dell'Ucraina all'Internet Corporation for Assigned Names and Numbers (ICANN) cercherebbe di revocare i domini emessi in Russia e di chiudere i server primari del Domain Name System (DNS) nel paese. Una mossa che impedirebbe effettivamente l'accesso ai siti internet russi, con il potenziale di mettere l'intero paese offline. Putin potrebbe essere pronto anche a questa eventualità, dato che nel 2019 ha firmato una legge sull'Internet sovrano e ha effettuato una serie di test specifici.Apple sospende la vendita di tutti i suoi prodotti in Russia. Lo afferma la società in una nota, annunciando che rimuoverà dal suo App Store la rete televisiva Russia Today e Sputnik.Netflix acquisisce Next Games. Mentre la Finlandia medita di unirsi alla NATO sulla scia della crisi Ucraina, il gigante dello streaming ha annunciato che avrebbe acquisito lo sviluppatore di giochi mobili con sede nel paese per un valore totale di 65 milioni di euro. L'accordo per l'acquisizione del creatore dei giochi Stranger Things e Walking Dead fa parte della più grande strategia di Netflix per costruire contenuti di gioco complementari al catalogo video.

We're joined by Adam Newbold (aka @neatnikllc (https://twitter.com/neatnikllc)), creator of omg.lol (https://omg.lol), to discuss what went into making his service and the experience of being an indie developer. Since agreeing to our interview, he has even become a listening Hemispherean! This month, we also launch our own Nostalgic November, inviting you to share a memory of anything from your past that brings a smile to your face, be it a movie, song, game or product—whatever! Simply send us a quick text, photo or video in one of the following ways: @HemisphericPod (https://mobile.twitter.com/HemisphericPod) on Twitter with #NostalgicNovember; @HemisphericViews (https://micro.blog/HemisphericViews) on Micro.blog; in our general Discord (https://discord.gg/mzdB2ug) chat; or by email to hello@hemisphericviews.com (https://hello@hemisphericviews.com). At the end of the month, we'll collect all entries into one comprehensive post on our blog to show off what is important to our listening community! To kick things off, see the nostalgic entries from Andrew (https://listen.hemisphericviews.com/articles/nostalgic-november-andrew), Jason (https://listen.hemisphericviews.com/articles/nostalgic-november-jason) and Martin (https://listen.hemisphericviews.com/articles/nostalgic-november-martin) on our blog. No Beachballs on Episode Burk 00:00:00 macOS Beach Ball (https://macpaw.com/how-to/the-spinning-wheel-on-mac)

Watch out world, AC/DC is on the show this week! (That's Andrew Canion and David Canion, as if you didn't already know!) On top of this, Andrew philosophises about the complicated world of email, Jason considers the meaning of 'cactus' and Martin inflicts a cruel competition on his co-hosts. *Slight hiccup with the audio for part of the show, sorry about that. We used a backup recording to save it, so you might notice that things sounds a little different. Introducing David Canion 00:00:00 Welcome, David!

In dieser Episode geht es um Namen im Internet und damit um das Domain Name System (DNS). Insbesondere geht es um Use Cases, d.h. was alles mit DNS gemacht wird, das nichts mit der ursprünglichen Funktion des DNS zu tun hat. Mehr zu Neulich im Internet unter https://www.neulich-im.net music by scottholmesmusic.com Quellen: DNS-Grundlagen und Fakten: Bind9.net: DNS RFCs, Clearingstelle Urheberrecht im Internet, Netzpolitik.org: Die Rückkehr der Netzsperren, How Many Domains Are There? – Domain Name Stats for 2021, Verisign: The Domain Name Industry Brief, Wikipedia: List of Internet top-level domains, Cloudflare: How Cloudflare analyzes 1M DNS queries per second, Use Case: Trademarks: World Intellectual Property Organization (WIPO): Frequently Asked Questions: Internet Domain Names, ICANN Archives: Uniform Domain Name Dispute Resolution Policy, Use Case: Trust/Security: Cloudflare: What is TLS (Transport Layer Security)?, Cloudflare: What is an SSL certificate? | How to get a free SSL certificate, Cloudflare: What is SNI? How TLS server name indication works, Shane Greenstein: How the Internet Became Commercial – Innovation, Privatization, and the Birth of New Network, CA/Browser (CAB) Forum, Dan York: The DANE Protocol – DNS-Based Authentication of Named Entities, Use Case: Service Discovery: RFC 6763: DNS-Based Service Disovery, Use Case: Traffic Steering: Akamai: Global Traffic Management, Akamai: Geolocation and DNS Traffic Management, Wikipedia: DNS Hijacking, RFC 2308: Negative Caching of DNS Queries (DNS NCACHE), Use Case: Tracking: RFC 6891: Extension Mechanisms for DNS (EDNS(0)), RFC 7871: Client Subnet in DNS Queries, Use Case: Zugangskontrolle: Wikipedia: Zugangserschwerungsgesetz Alle weiteren Quellen unter https://www.neulich-im.net --- Send in a voice message: https://podcasters.spotify.com/pod/show/neulich-im-netz/message

The Domain Name System -- DNS -- is like the Internet's phone book. It's how computers match URLs to IP addresses in order to help you do things like look at web pages or send emails.Sure, the system seems like an obvious way of structuring the Internet now. After all, can you imagine the Web without Google.com and Amazon.com and Facebook.com? But the current structure of Internet domain names wasn't always an obvious solution to the problem.In this episode of Web Masters, you'll hear how the Domain Name System came into being from the man who invented DNS, Paul Mockapetris. Paul's vision for Internet routing was critical for making the Internet infinitely scalable. But, when he proposed it, he wasn't actually in a position to implement his vision. So, before his system could be adopted, he had to make sure nobody else's proposals were ever considered. Luckily, he was given a perfect opportunity to intervene.For a complete transcript of the episode, click here.

O Amazon Route 53 é um web service Domain Name System (DNS) na nuvem altamente disponível e escalável. E Flávio Rescia traz uma explicação bem completa como esse recurso pode ser uma maneira totalmente confiável e com baixo custo de direcionar os usuários finais aos aplicativos de Internet. Confere aí! Entre no nosso grupo do Telegram e tire mais dúvidas Cloud Evangelists BR: https://t.me/cloudevangelist Ou acesse: https://www.darede.com.br/

An ounce of prevention is worth a pound of cure. **Benjamin Franklin** The concept of risk is ubiquitous across the cybersecurity landscape. In this day and age, it is difficult to envision any security-conscious organization not having alluded, hopefully more than once, to the serious consequences attached to avoiding the subject, particularly when it comes to protecting its most sensitive digital assets and personal data. These repercussions, in both monetary and non-monetary terms, can be far-reaching in the amount of damage they can cause by the resultant corporate disarray and overall loss of reputation. Thus, entire governance structures are distinctly preconditioned with the relevant identification of the digital infrastructure as well as the adequate assessment of their threat ecosystem, prior to consigning any additional items onto the risk registers. While modern businesses can't anticipate every possible threat there is, a few solutions have evolved over the years to become proficient at preventing, or altogether disallowing, the most common types of attack patterns and intrusion attempts known throughout the cyber milieu. The leading principle here is known as the information classification process, commonly assigned, in typical organizational fashion, to data owners and similar stakeholders in what is considered the initial step in the domain of business continuity planning and disaster recovery. One of these approaches entails the concept of attack surface management (ASM), an overarching methodology capable of providing real-time discovery, classification, and continuous examination of an entity's digital assets whose misconfiguration or unintended exposure may lead to a serious breach scenario. The ability of techniques such as ASM to effectively shut the door in the face of threat actors seeking to leverage even the most sophisticated attack vectors is a significant testimony to its foregoing validity and importance. This blogpost will highlight the risks associated with the use of private IP (Internet Protocol) addresses in public Domain Name System (DNS) records as they extend the possibility of a cyber attack on internal address spaces and attributed domains. It will briefly re-examine the historical prohibition set forth by RFC 1918 that sought to limit the use of these address blocks to within enterprise boundaries, as well as the unnecessary technical challenges that arise from their misuse. Let's take a look. Private IP addresses in a nutshell IP addresses long journey to present-day operations began in the 1970's when the Defense Advanced Research Projects Agency (DARPA) designed the first protocol specifications. The concept was shaped around the need to interconnect computer communication networks, called packet-switched networks, where sources and destinations were represented by hosts identified by fixed-length numerical addresses known as Internet Protocol addresses, or IPs for short. The protocol contained additional features such as the ability to fragment long datagrams to allow efficient data transmission through less capable network channels and, most importantly, an abstraction of the time-to-live (TTL) consistency mechanism to prevent data packets from circulating indefinitely. According to the standards established by the Internet Engineering Task Force (IETF), IPv4 (IP version 4) was to define a set of private address spaces (see image below) to allow an ever-depleting subset of 2 to the power of 32 possible IPs to be effectively routed as to not create ambiguity between publicly-connected enterprises. It was also IETF's decisive action that established that applications that did not require external connectivity should be confined to any one of these non-routable reserved classes without further intervention from Internet authorities. As previously mentioned, in a race to put a stopgap to the problem of IP address exhaustion, RFC 1918 became the de facto referenc...

This episode is sponsored by Cloud Academy - get 50% off their monthly price by using the unique code "LEARNAWS" during checkout at https://cloudacademy.comTwitter feedback @original_homAmazon Route 53 is a highly available and scalable cloud Domain Name System (DNS) web service. It is designed to give developers and businesses an extremely reliable and cost effective way to route end users to Internet applications by translating names like www.example.com into the numeric IP addresses like 192.0.2.1 that computers use to connect to each other. Amazon Route 53 is fully compliant with IPv6 as well.

A group of researchers from UC Riverside and Tsinghua University announced a new attack against the Domain Name System (DNS) called SAD DNS (Side channel AttackeD DNS). In this video I explain this attack 0:00 Intro 1:00 What is DNS? 3:10 Original DNS Poisoning 6:30 DNS Poisoning with Fragmentation Attack 9:30 ICMP Explained 13:00 DNS Poisoning with ICMP Error Messages Resources https://blog.cloudflare.com/sad-dns-explained/ https://www.saddns.net/ https://bit.ly/3lHTn45 https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol --- Send in a voice message: https://anchor.fm/hnasr/message

Is the "Last Digital Currency" not going to be blockchain based but cloud based? Sean Worthington of CloudCoin believes so. He calls CloudCoin the “Last Digital Currency” because it is the first currency to obtain perfection based on the “Theory of Perfect Money.” Rather than using a blockchain, CloudCoin utilizes an adaptation of the global Domain Name System (DNS) called RAIDA (Redundant Array of Independent Detection Agents). Note that the DSN is a datastore that has never gone down globally since 1985 and processes 2 trillion queries each day. Like the Blockchain and the DNS, the RAIDA provides “Data Supremacy” and cannot be taken down by hackers, governments or even nuclear weapons. Learn More in our Sponsor Spotlight or at https://cloudcoin.global

In this 1 hour-long themed episode of AWS TechChat, join us as we sail to the Edge and demystify many of the core concepts that occur before end-user requests are made. We start the show setting a foundation of Domain Name System (DNS), why it is important, before talking about Amazon Route 53, a highly available and scalable cloud DNS Service. It is also a full featured DNS service that is API, SDK, and CLI driven. We then introduce the concept of Content Delivery Networks (CDN), and talk about Amazon CloudFront which speeds up the distribution of your static and dynamic web content. Amazon CloudFront also delivers the content through a worldwide network of data centers called edge locations. Amazon CloudFront allows you to run AWS Lambda functions at the edge. Lambda@Edge is an extension of AWS Lambda which lets you execute functions and customize the content Amazon CloudFront delivers. Before closing out, we talk about AWS Global Accelerator, a service that improves the availability and performance of your applications with local or global users. It provides static IP addresses that act as a fixed entry point to your application endpoints in a single or multiple AWS Regions. Speakers: Shane Baldacchino - Edge Specialist Solutions Architect, ANZ, AWS Dean Samuels - Lead Technologist, ASEAN, AWS Resources: Amazon CloudFront - https://aws.amazon.com/cloudfront/ Amazon Route53 - https://aws.amazon.com/route53/ AWS Global Accelerator - https://aws.amazon.com/global-accelerator/ AWS Events: AWS Builders Online Series http://aws.amazon.com/events/builders-online-series/ AWS Summit Online on-demand - http://aws.amazon.com/events/summits/online AWS Events and Webinars - http://aws.amazon.com/events/

The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. Most prominently, it translates more readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. By providing a worldwide, distributed directory service, the Domain Name System has been an essential component of the functionality of the Internet since 1985.

The EVP Engineering and Chief DNS Architect at Infoblox, Cricket Liu, joins us on Threat Talk to talk about DNS Flag Days – why we need them and how they are improving the internet.  DNS Flag Days serve notices to obsolete Domain Name System (DNS) servers that existing accommodations to provide them with compatibility for pre-1999 standards will be phased out.  The Flag Days attempt to: Speed up DNS Improve DNS reliability Improve DNS security In 1999, DNS was extended with eDNS(0), yet servers incompatible with eDNS(0) continue to be used today.  To improve the performance of the internet, the 2019 DNS flag day temporarily ceased to support those legacy DNS servers. The 2020 Flag Day will tackle the maximum DNS message size to bring them down under 1232 bytes.  This will stop DNS message fragmentation and improve both the reliability and security of DNS. You can find this interview, and many more, by subscribing to the ThreatTalk podcast on Apple Podcasts or on Spotify.

Dieses Mal bringt Stefan sein Thema DNS zu ende. Jedoch gibt es vorher einen ausführlichen Datenverlust- und News-Block da es die einzige Folge des Monats ist. Warum dieses so ist, wird in der Hausmeisterei geklärt, sowie ein Audiokommentar eingespielt, der den Podcast nach der letzten Sendung erreichte.

Nachdem die Helden der Informations- und Datensicherheit es endlich einmal geschafft haben ohne “bla bla” vor dem Intro eine Folge zu beginnen, widmet sich Stefan dem Domain Name System und gibt einen überblick über die Historie dahinter und einen wirklich rudimentären Einblick wie es funktioniert. Kündigt jedoch bereits Vertiefungen an. Zwischendurch lenkt Sven Stefan ab, indem er sein rechtes Ohr lüftet. Disclaimer In diesem Podcast werden Techniken oder Hardware vorgestellt, die geeignet sind, externe Geräte anzugreifen. Dies geschieht ausschließlich zu Bildungszwecken, denn nur, wenn man die Angriffstechniken kennt, kann man sich effektiv davor schützen. Denkt immer daran, diese Techniken oder Hardware nur bei Geräten anzuwenden, deren Eigner oder Nutzer das erlaubt haben.Der unerlaubte Zugriff auf fremde Infrastruktur ist strafbar (In Deutschland §202a, §202b, §202c StGB).

My mind has been on the Domain Name System (DNS) server for about a week now. I've been mulling over whether VPNs are necessary and what level of trust should be placed in a DNS provider. It's evident not to trust your ISP's DNS since some companies have been caught manipulating the data or using you DNS metadata to sell to other companies. Both of which suck. This collection of data via the DNS still happens even when a user connects to a VPN. The data between the user and the site is encrypted but the request to what IP address ties to the requested domain name, is not. Worst of all the user is almost always using their ISP's default servers which they control. --- Support this podcast: https://anchor.fm/hackerculture/support

Are you prepared for the change of the security key at the center of the Domain Name System (DNS)? In this episode I talk about DNS, DNSSEC, and the “root key rollover” that is happening on October 11. Find out more at: http://www.circleid.com/posts/20181005_how_to_prepare_for_dnssec_root_ksk_rollover_on_october_11_2018/

In an age of digital identity, how do we protect ourselves in an increasingly insecure world? In 2008, Dan Kaminsky identified a critical flaw in the internet’s Domain Name System (DNS) and led the largest synchronized fix to the internet’s infrastructure of all time. Today, he’s Chief Scientist and cofounder of White Ops. Topics include: the great cities of the world that were proven vulnerable, and burned to the ground, computer worms, why it’s easier than ever to hit the WHOLE world with an attack, crypto’s role in proliferating these attacks, evil hacking as a kind of mind control!, how – in the context of Mars – to start over and get security right, and building an elite team of security hackers dedicated to fighting crime and fixing bugs around the world.

Wouldn’t it be great if you could speed up every single website you visit without paying a dime? Every time you go to a website, your computer or smartphone first has to look up how to get to get there - just like we used to have to look up people’s numbers in the phone book. The service we all use is the Domain Name System (DNS), and by default, your DNS provider is probably not very fast. Today, John Graham-Cumming (the CTO of Cloudflare) will carefully explain how this works and why his company’s 1.1.1.1 DNS service is so much faster than the default one you’re probably all using. Furthermore, Cloudflare’s service will keep your web surfing habits totally private - something your default service is almost surely NOT doing. John Graham-Cumming, CTO of Cloudflare, is a computer programmer and author. He studied mathematics and computation at Oxford and stayed for a doctorate in computer security. As a programmer he has worked in Silicon Valley and New York, the UK, Germany, and France. His open source POPFile program won a Jolt Productivity Award in 2004. John is the author of a travel book for scientists published in 2009 called The Geek Atlas and has written articles for The Times, The Guardian, The Sunday Times, the San Francisco Chronicle, New Scientist and other publications. For Further Insight: Website: jgc.org Follow on Twitter: https://twitter.com/jgrahamc Cloudflare’s 1.1.1.1 DNS service Steve Gibson’s DNS Benchmarking tool: https://www.grc.com/dns/benchmark.htm DNS Perf speed check: https://www.dnsperf.com/

In today’s episode we try to make the confusing topic of Domain Name System (DNS) a bit less confusing.

For several days not that long ago, Jordan Reid's site, ramshackleglam.com, did not belong to her. She got it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a massive sting operation. Here's her story.  Written by Jordan Reid: https://twitter.com/ramshackleglam Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2EA3OjL Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript:  For several days not so long ago, RamshackleGlam.com — the domain name that I have owned and operated since March of 2010 — did not belong to me, but rather to a man who goes by the name “bahbouh” on an auction website called Flippa, and who was attempting to sell off the site to the highest bidder (with a “Buy It Now” price of $30,000.00). He promised the winner my traffic, my files, and my data, and suggested that I was available “for hire” to continue writing posts (alternatively, he was willing to provide the winner with “high-quality articles” and “SEO advice” to maintain the site’s traffic post-sale). I learned that my site was stolen on a Saturday. Three days later I had it back, but only after the involvement of fifty or so employees of six different companies, middle-of-the-night conferences with lawyers, FBI intervention, and what amounted to a sting operation that probably should have starred Sandra Bullock instead of…well…me. Of course I’ve heard of identity theft, and of cyber hacking, but honestly, my attitude towards these things was very much “it could never happen to me.” And even if it did…I didn’t exactly understand why it was such a huge deal. Couldn’t you just explain to people what had happened, prove who you were, and sort it all out? We live in such a highly documented world, it seemed completely impossible to me that someone could actually get away with pretending to be someone else with any real consequences beyond a few phone calls and some irritation. It’s much, much worse — more threatening, more upsetting, and more difficult (if not impossible) to fix — than I’d ever imagined. I found out about the hacking from my father. His friend Anthony (who runs a web development and consulting company called ThoughtBox) had been surfing around on Flippa and had — in an impossibly lucky coincidence — noticed that my site was up for auction, with what appeared to be a highly suspicious listing. Suddenly, I remembered the email I had gotten the day before — an email that I had disregarded as spam — from someone “interested in the purchase” of my “weblog.” I remembered the notification from YouTube that someone had accessed my account from a different location — a notification I had ignored, assuming that I had logged in on a mobile device or that my husband had accidentally logged into my account instead of his own. But even after I saw the listing, I didn’t panic: this seemed like something that could be fixed with a couple of emails. Except the auction site was located in Australia and didn’t appear to have a phone number, and when I sent an email with a scanned ID and proof of ownership what I got back was a form letter. And when I called HostMonster, the site I pay to operate my website, I discovered that I was no longer the owner of my site: someone had used their email confirmation system to authorize the transfer of my domain name into a private account at GoDaddy (another web registrar service of whom I’m also a client). Why is this a big deal? If you have a business that depends on a URL, you understand why this was such upsetting news: With control over my website’s domain name, a hacker would be able to take the site down, or redirect it elsewhere. Further, it was later verified that the hacker had control over all of the site’s content, as well; he could have just rerouted everything I’ve ever written to any location he wanted. Ramshackle Glam may be “just” a lifestyle blog about things like parenting and fashion and decor…but it’s also a site that I’ve spent five years of my life building, and the idea of it falling into the hands of someone with malicious intent was heartbreaking. I could switch to a new URL and export a copy of my content (which I do back up), but that would result in the loss of a substantial amount of traffic. The website is my primary source of income, and with a house, two children, a book coming out, and a husband in business school, this was not a joke. The loss of my URL had the potential to be devastating for my business and for my family in a very real way. So what did I do? The events of the next few days were complicated, so rather than go through them chronologically I’m going to explain how each path I took ended up panning out (I’m going into detail so that I can be as much help as possible to anyone who goes through this themselves). 1. I tried to resolve the situation directly with GoDaddy and HostMonster. This did not work. From Sunday through Tuesday, I spent most of the day (and much of the night) on the phone with GoDaddy, HostMonster, or both at the same time, and nearly every person I spoke with gave me the same response: “Sorry, can’t help you.” HostMonster maintained that because they no longer controlled the domain name, there was nothing they could do. GoDaddy maintained that because the account was private and the person had obtained ownership of the domain through a transfer from HostMonster, there was nothing they could do. What finally made a difference: I cited ICANN’s policy on Domain Name Dispute Resolution.* This got my case upgraded, but it did not result in action. Here’s why: the legal department at HostMonster informed me that in order for them to initiate a transfer dispute that would result in GoDaddy releasing the domain back to me, their “internal investigation” would have to turn up evidence that they had done something wrong in releasing the site. In other words, they would have to admit that they had screwed up…which would in turn open them up to a lawsuit. Needless to say, I never heard from the legal department again. Despite the fact that everyone seemed clear on the fact that I owned my website and that it had been transferred without my authorization, nothing was going to be done unless I initiated a time-consuming and costly lawsuit that, in any case, would not result in action quick enough to save my domain name from being sold. So that avenue came to an end. 2. I called the FBI. This was a major step in the right direction. The morning after I found out about the unauthorized transfer, I also called the FBI. I felt silly and dramatic making the phone call, but the reality is that this is an international cyber crime issue, and that’s FBI territory. And this is my business. It’s how I support my family, and it may be a “small matter” in the grand scheme of things, but it is not a small matter to me. And let me tell you: of all the surprises I’ve had over the past week or so, most surprising of all has been the FBI. They responded immediately, with follow-up phone calls and emails, an in-person interview with two special agents at my own home within 24 hours, and a follow-up visit from two agents yesterday. Beyond that, each and every agent I have interacted with over the past week has been, without fail, compassionate, thoughtful, invested, respectful, and committed to action…in addition to treating me not like a case number, but like a human. What I expected was to leave a message with a general mailbox and at some point receive a form letter; I certainly did not expect to see an active investigation opened immediately. I’m not going to write more about the investigation because it’s still ongoing (although I did ask for and receive permission to write about this), but I think it’s important to say how absolutely blown away I have been by the FBI’s response. 3. I tried to regain control by dealing directly with the “seller”. This worked, but not without considerable drama. While all of the above was going on, I was also working to regain control over the site directly from the individual who was trying to sell it. I didn’t want to contact the “seller” directly, because I felt that if he thought the “real” owner of the site was aware of the sale, he would try to extort more money. So I asked Anthony — the person who had found the original listing, and who had an active account with a positive history on Flippa — to DM “bahbouh” to see if he was interested in a “private sale”. After some back-and-forth we reached an agreement, and it was decided that a third-party money-transfer website (Escrow.com) would be used to make the sale: the money would only be released to the seller upon confirmation that the domain name had been transferred. This appeared to be going smoothly until Tuesday night, when the seller suddenly demanded that the funds be released immediately (prior to receipt of the website). When we pushed back, he announced that he was selling it to someone else: “Sorry, bye.” So here was my thought process: if we did not release the money to the seller, we were guaranteed to not get the website. If we did release the money to him, there was a possibility that he would take the money and run, and also a possibility that he would deliver the site as promised. It wasn’t a gamble I wanted to take…but I didn’t see any option. And so I authorized the wire transfer. I spent twenty minutes sitting in front of the dummy GoDaddy account I had created to receive the domain name from the seller, waiting to see whether I was out thousands of dollars and a domain name, or just thousands of dollars. And then it came through. I immediately transferred the domain into a different account and placed it (and all of my other domain names) on what amounted to lockdown. And then I called the wire transfer company and placed a stop on the payment. The end result RamshackleGlam.com is back in my possession, thanks to a number of people who dedicated hours (in some cases days) out of their lives to doing whatever they could to help me. My other accounts — bank accounts, et cetera — have been secured. I don’t have my money back yet, but the man who stole my site from me doesn’t have it, either, and won’t be getting it, ever. And that’s an ending I’m pretty damn thrilled with. So why am I still angry? Of course I’m angry with the person or people who stole the site, but that’s out of my hands. The reason I’m writing this post is to let people know that this really can happen — to anyone — and to offer suggestions for how to minimize the chances that it will happen to you (below), but beyond that, I’m writing this post because this incident made me very, very angry at GoDaddy and HostMonster. And I want you to know why. No one at either company questioned my statement (supported by written proof) that the website belonged to me. No one doubted that it had been transferred without my authority. And yet I had to spend days — days during which the hacker could have done virtually anything he wanted — trying to reach one single person who was able to do anything, because the support staff and supervisors I spoke with (who had to have numbered fifty or more) were completely uninformed as to how to handle this situation beyond saying, “Jeez, that sucks. Can’t help you.” And once I reached people who could help me — who could literally make a single phone call or push a single button and return my property to me (or simply freeze it so that it could not be sold or destroyed) — they would not. They hid behind their legal departments and refused to do anything, knowing full well that their inaction would force me to either interact with and pay off a criminal, or lose an essential component of my business. And hackers know that these companies will do this. They rely on it. There is a serious problem when a criminal enterprise not only exists “despite” a company’s policies, but actually thrives as a direct result of that company’s prioritization of their own interests over the security of the clients they allegedly “protect”. Do I understand why companies like HostMonster and GoDaddy are focused on protecting themselves against lawsuits? Of course I do. But the fact is that they not only do not “help” their customers, but actively contribute to creating situations that threaten small businesses and the families that they support. And these companies know that when they stonewall clients whose property has obviously been stolen that these clients will have no other recourse than to pay off criminals or watch their businesses — sometimes their very lives — collapse. They know that by standing in the way of immediate action they create the very environment that these criminals depend upon to perpetuate their business model. And they do nothing. This has to change. My opinion, for what it’s worth Support personnel at hosting companies should be made intimately familiar with ICANN regulations involving domain disputes, and should be able to initiate a plan of action the first time a client makes them aware of a situation, not after hours and hours of repeated calls. Further, the establishment of a TEAC** should result in an immediate freeze on the account in dispute until the situation has been resolved. This should not require an admission of culpability on the part of any parties; simply an acknowledgement that a dispute exists and an awareness that while the dispute exists the domain must be held safe from sale or transfer. What you can do to reduce the chances that this will happen to you: Have a really, really good password, and change it often. Your password should not contain “real” words (and definitely not more than one real word in immediate proximity, like “whitecat” or “angrybird”), and should contain capital letters, numbers and symbols. The best passwords of all look like total nonsense. If possible, use a separate computer (an old one or a cheap one purchased for this purpose) for things like banking; if your family computer is the same one that you use for bank transactions you risk having your kids click on a bad link that results in a hacking. Turn off your computer and personal devices when they’re not in use. Have antivirus software on your computer (but remember that virus scans only catch 30–40% of viruses, so unfortunately a “clean” check doesn’t necessarily mean that you’re safe). Purchase CyberRisk Insurance (learn more about it here; it basically protects businesses from cyber attacks and data breaches. But if it does happen to you, here’s what to do: Begin taking careful notes (and screenshots) immediately. Don’t delete any emails or other information; it could all be important later on. Immediately change all of your passwords (including — but not limited to — domain registrar, website hosting, website login information, email, bank accounts, wireless home electronics, and Apple ID) according to the rules stated below. I changed mine every few hours while this situation was still up in the air, and am continuing to change them every few days for the time being. Contact the registrar(s), citing the ICANN policy below, and see if together you can arrive at a speedy resolution. Don’t be surprised if you find yourself running into dead ends. Make sure to inquire about “filters” and “rules” that may have been placed on your email (basically, any kind of device that the hackers may have placed to forward emails, et cetera). Contact appropriate law enforcement (I contacted the FBI because it appeared to be an international issue, and was at the very least an interstate issue because Escrow.com is located in California, and I’m in New York). Note: Every situation is different, and I can’t wholeheartedly recommend the steps that I took that ultimately resulted in me regaining control over my domain name largely because they involved interacting with criminals. Obviously that isn’t ideal, and can have unpredictable consequences. (Although my husband says that he would like it to be known that he thinks I’m a huge badass. While this is ordinarily very far from the truth, in this specific instance…I’ll take it.) The End. (That was long. Thanks for reading.) *ICann.Org is the Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for managing and coordinating the Domain Name System (DNS). ICANN’s policy on Domain Name Dispute Resolution essentially states that in the case of a domain dispute, the Losing Registrar (the registrar that maintained possession of the domain name pre-transfer, as opposed to the “Winning Registrar”, who maintains possession of the domain name post-transfer). must immediately establish a Transfer Emergency Action Contact (“TEAC“) in an effort to get the ball rolling in the direction of resolution right away). Once I had this information, my case was immediately upgraded. **TEAC: A contact that is established by ICANN and used by other registrars and ICANN if there is a need to quickly address issues with domain transfers between two registrars. The contact must respond to inquiries within four hours, though final resolution may take longer.

Pull Request #35 - 15 Oct 2017 - What's In A Name? ▶ We discuss the modern Domain Name System (DNS), everything from how it works to how it's secure. PLUS - A bot that tracks edits to Wikipedia from the US Congress, and how smartphones are ruining humanity. AND, OF COURSE - Theresa May murders the Internet!~ + Eric Newman, Tyler Dinner, & Chris Grabowski

In 2016 we saw new provider directory regulations from CMS and several states, including the particularly "toothy" SB-137 in California. The new rules are intended to hold health plans accountable for any inaccurate and/or incomplete information in their provider directories. The national conversation is focused intently on the consumer side. That is, bad information makes it difficult for patients to make educated decisions when they select plans and can lead to access issues down the road. The consumer issues are real, but only scratch the surface of the overall provider data problems we face. Health plans and provider groups struggle to keep each other up-to-date making communication more difficult and less efficient. Even departments within the same organization have trouble staying in sync and that leads to all types of problems in our day-to-day operations. Government and regulatory bodies are hindered in their efforts to ensure appropriate access and coverage in our health plans. When you put this all together you'll begin to see why I call provider directories the ultimate death by paper cut in healthcare. This is not as simple as it sounds. Kicking-off the Provider Directory Series Over the next 6-8 weeks The #HCBiz Show! will be focused on the provider directory problem. We'll talk with experts who are dealing with this issue from all sides to understand what the issue is, why it exists today, and how we can fix it. For background, you can check out our video conversation and the accompanying post from last year. You may also enjoy our breakdown of CMS' first review of provider directory accuracy. On this episode, co-hosts Don Lee and Shahid Shah give an overview of the issues and talk about the upcoming series. You'll hear: Lessons learned from our Infection Prevention and Control Series (1:05) The difference between being Accountable and Responsible and how that can predict a solution's success or failure very early on (2:42) What is the Provider Directory issue? (9:15) Why narrow networks require accuracy and adequacy (11:30) Why half of the nation's health plans would be fined if CMS implemented them today (14:00) How inaccurate provider directories impact patients (15:00) How the fines are making someone accountable for the first time (18:00) Why it's hard to keep just 15-20 basic pieces of information up-to-date (19:00) How the need for health plans to let patients understand their narrow networks conflicts with their desire to keep their competitors in the dark (21:20) How the bad data affects health plans internal day-to-day operations (22:20) What can we learn from the internet's Domain Name System (DNS) (25:50) Who is responsible vs. who is accountable (26:40) How are provider groups and health systems impacted by bad provider data (27:25) How organizations like the AHIP Innovation Lab can help bring industry leaders together on problems like this (28:40) Why it's important to apply accountability at the right "height" within an organization (30:24) How a federated solution might work at the national level (34:00) How to enable collaboration in a competitive market (38:20) Why it makes sense that the accountability is being placed on the health plans today (40:25) Weekly Updates If you like what we're doing here, then please consider signing up for our weekly newsletter. You'll get one email from me each week detailing: New podcast episodes and blog posts. Content or ideas that I've found valuable in the past week. Insider info about the show like stats, upcoming episodes and future plans that I won't put anywhere else. The question of the week. Plain text and straight from the heart :) No SPAM or fancy graphics and you can unsubscribe with a single click anytime. The #HCBiz Show! is produced by Glide Health IT, LLC in partnership with Netspective Media.   Music by StudioEtar

The Domain Name System (DNS) is an essential component of the Internet, a virtual phone book of names and numbers, but we rarely think about it until something goes wrong. DNS also serves as the backbone for other services critical to organizations including email, external web access, file sharing and voice over IP (VoIP). There are steps, however, that network administrators can take to ensure the security and resilience of their DNS infrastructure and avoid security pitfalls. In this podcast, Mark Langston discusses best practices for designing a secure, reliable DNS infrastructure. Listen on Apple Podcasts.

The internet has long been seen as a force of global connection,  But this notion of a global internet has never been entirely accurate. Language barriers, access limitations, censorship and the human impulse to stay within your own social circles contribute to us staying local.  And then there is the larger architecture of the internet.  This podcast looks at at how this architecture, specifically the Domain Name System (DNS) has been used and developed in China to localize control there. In this podcast, Adriene Lilly talks to Séverine Arsène, a researcher at the French Centre for Research on Contemporary China in Hong Kong and Chief Editor of China Perspectives – a journal dedicated to cultural, political and economic trends in China. She is also author of the recent article Internet Domain Names in China: Articulating Local Control with Global Connectivity part of a special feature of China Perspectives 'Shaping the Chinese Internet' The internet has long been seen as a force of global connection, bringing together people of different cultural, political and economic backgrounds. Understood as a horizontal network and a community that is structurally decentralized. But this notion of a global internet has never been entirely accurate. Language barriers, access limitations, censorship and the human impulse to stay within your own social circles contribute to us staying local. Beyond social constraints, there is the larger architecture of the internet to take into account. Essential structures that hold the internet in place, yet remain mostly unknown. Today, we're looking at how this architecture has been used and developed in China to localize control there. Understanding the Domain Names System is a big step in understanding the architecture of the internet. The Domain Names System, or DNS, is the global addressing system for the internet. You can think of the DNS like a phonebook. It takes numbers (IP addresses) and attributes them to names (domain names). When you type in an address in your browser (i.e.podacademy.org) your using the DNS to look up and call the number in this global phonebook. This global system is coordinated by the Internet Corporation for Assigned Names and Numbers or ICANN. China was a major pioneer in using the DNS as a political tool, creating a vast web of regulation, censorship and blocking. This has been an evolving system since the early days of the internet, and continues to change to this day. Only last month,a new draft law was reported that could force website owners operating in China to apply for China-base domain names – this means websites ending in .com or .net must also register with .cn or Chinese character domain names like .中国(meaning “.China”) or .公司 (meaning “.Corporation”). Like many similar regulations, the draft of this law is vague in its wording and its exact implications are yet to be seen. In this episode Séverine discusses how laws like this have evolved over time and what they might really mean. “The very point of using the DNS to block particular websites, or using keyword filtering, is to have a selective blocking or a selective connection to the global internet. It enables the Chinese state to have the best of both. The best of the global internet: access to trade, to fashion trends, to self-expression in a certain way - it helps people to vent off, express their identities, their wills, without necessarily being critical about the state of their own country. And, at the same time is allows a certain amount of political control...” This selective access has become known as 'The Great Firewall of China.' The term can be misleading, implying an internet that is structurally isolated from the rest of the world when, in reality, it is more a 'selective' access. “...the term “Great Firewall” was invented at the end of the 1990s/2000s, it is a very powerful image to represent a separated network that would be really very different than the rest of the...

A brilliant fact about crypto-economic blockchains is that they enable the construction of naming systems that transcend limits imposed by Zooko’s triangle. Traditional naming systems such as human names, Domain Name System (DNS) and Facebook profile names are subject to Zooko’s triangle and cannot be secure, human memorable and decentralised at once. For instance human names such as Meher Roy are human-memorable and decentralised but not secure (nothing prevents hundreds of people being called Meher Roy). Domain Names like are secure and human-memorable but require a central authority to hand out names. OneName leverages Bitcoin to build a Global Identification system called blockchain ID. Blockchain IDs for users can be associated with real world identity data such as social media profiles, government issued papers etc. In this episode we converse with Ryan Shea and Muneeb Ali, co-founders and leaders of OneName, Blockstore and BlockStack. They explain the rationale and vision behind their push for a Global Decentralised Identification and Verification system. Topics covered in this episode: Zooko’s triangle and how Bitcoin breaks the triangle The general idea behind blockchain ID, how it works and its component transactions Why OneName migrated their blockchain ID system from the Namecoin to the Bitcoin blockchain Technical design of Blockstore and how it enables decentralised storage and association of large datasets to blockchain IDs Vision and use cases for Decentralised Identity, authentication and identity verification. The notion of Probabilistic Identity Episode links: Intentional Naming System Zooko's triangle Why Onename is Migrating to the Bitcoin Blockchain Blockchain ID Organization of Schemas Blockstack BlockStore This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/101

Secure Random By Default Dan Kaminsky Chief Scientist, White Ops As a general rule in security, we have learned that the best way to achieve security is to enable it by default. However, across operating systems and languages, random number generation is always exposed via two separate and most assuredly unequal APIs -- insecure and default, and secure but obscure. Why not fix this? Why not make JavaScript and PHP and Java and Python and even libc rand() return strong entropy? What are the issues stopping us? Should we just shell back to /dev/urandom, or is there merit to userspace entropy gathering? How does fork() and virtualization impact the question? What of performance, and memory consumption, and headless machines? Turns out the above questions are not actually rhetorical. Just because a change might be a good idea doesn't mean it's a simple one. This will be a deep dive, but one that I believe will actually yield a fix for the repeated *real world* failures of random number generation systems. Dan Kaminsky has been a noted security researcher for over a decade, and has spent his career advising Fortune 500 companies such as Cisco, Avaya, and Microsoft.Dan spent three years working with Microsoft on their Vista, Server 2008, and Windows 7 releases. Dan is best known for his work finding a critical flaw in the Internet’s Domain Name System (DNS), and for leading what became the largest synchronized fix to the Internet’s infrastructure of all time. Of the seven Recovery Key Shareholders who possess the ability to restore the DNS root keys, Dan is the American representative. Dan is presently developing systems to reduce the cost and complexity of securing critical infrastructure.

How can we best protect the Domain Name System (DNS) against distributed denial of service (DDoS) attacks? There's a new report from ICANN's SSAC on this issue: http://www.internetsociety.org/deploy360/blog/2014/02/ssac-issues-new-report-on-ddos-attacks-against-dns/

Today’s episode features Sean and Randy from beAutomated. Today’s topic is understanding Domain Name System (DNS), how it works and how to use it to your benefit.

The Domain Name System (DNS) is one of the components most critical toInternet functionality. The ubiquity of the DNS necessitates both theaccuracy and availability of responses. While the DNS SecurityExtensions (DNSSEC) add authentication to the DNS, they also increasethe complexity of an already complex name resolution system. Manydeployments have suffered from server misconfiguration or maintenanceneglect which increase the likelihood of name resolution failure for adomain name, even if servers are responsive.Our research introduces metrics for quantifying DNSSEC availability andevaluates these metrics on production signed DNS zones to show thepervasiveness of misconfiguration. We present methodology forincreasing robustness of name resolution in the presence of DNSSECmisconfiguration. In our survey of production signed zones, we observethat nearly one-third of the validation errors detected might bemitigated using the technique proposed in our research.As part of my talk, I will also demo an online DNS visualization tooldesigned to assist administrators in identifying critical issues withtheir DNSSEC deployments.This is joint work with researchers at UC Davis and Intel Corporation. About the speaker: Casey Deccio is a Senior Member of Technical Staff at Sandia NationalLaboratories in Livermore, CA. He joined Sandia in 2004 after receivinghis BS and MS degrees in Computer Science from Brigham Young University,and he received his PhD in Computer Science from the University ofCalifornia, Davis in 2010. Casey's research interests lie primarily inmodeling and availability analysis of DNS and DNSSEC, and he leadsSandia's DNSSEC deployment efforts.

The Domain Name System (DNS) is one of the components most critical to Internet functionality. The ubiquity of the DNS necessitates both the accuracy and availability of responses. While the DNS Security Extensions (DNSSEC) add authentication to the DNS, they also increase the complexity of an already complex name resolution system. Many deployments have suffered from server misconfiguration or maintenance neglect which increase the likelihood of name resolution failure for a domain name, even if servers are responsive. Our research introduces metrics for quantifying DNSSEC availability and evaluates these metrics on production signed DNS zones to show the pervasiveness of misconfiguration. We present methodology for increasing robustness of name resolution in the presence of DNSSEC misconfiguration. In our survey of production signed zones, we observe that nearly one-third of the validation errors detected might be mitigated using the technique proposed in our research. As part of my talk, I will also demo an online DNS visualization tool designed to assist administrators in identifying critical issues with their DNSSEC deployments. This is joint work with researchers at UC Davis and Intel Corporation.

Intro: Two weeks ago we gave an overview of IPv6. This week we take a look at some of the technical details for this protocol. Mike: Gordon, a couple of weeks ago we discussed Ipv6 - can you give us a quick review - what's the difference between IPv4 and IPv6? The most obvious distinguishing feature of IPv6 is its use of much larger addresses. The size of an address in IPv6 is 128 bits, which is four times the larger than an IPv4 address. A 32-bit address space allows for 232 or 4,294,967,296 possible addresses. A 128-bit address space allows for 2 28 or 340,282,366,920,938,463,463,374,607,431,768,211,456 (or 3.4x1038) possible addresses. In the late 1970s when the IPv4 address space was designed, it was unimaginable that it could be exhausted. However, due to changes in technology and an allocation practice that did not anticipate the recent explosion of hosts on the Internet, the IPv4 address space was consumed to the point that by 1992 it was clear a replacement would be necessary. With IPv6, it is even harder to conceive that the IPv6 address space will be consumed. Mike: It's not just to have more addresses though, is it? It is important to remember that the decision to make the IPv6 address 128 bits in length was not so that every square inch of the Earth could have 4.3x1020 addresses. Rather, the relatively large size of the IPv6 address is designed to be subdivided into hierarchical routing domains that reflect the topology of the modern-day Internet. The use of 128 bits allows for multiple levels of hierarchy and flexibility in designing hierarchical addressing and routing that is currently lacking on the IPv4-based Internet. Mike: Is there a specific RFC for IPv6? The IPv6 addressing architecture is described in RFC 2373. Mike: I know there is some basic terminology associated with IPv6. Can you describe Nodes and Interfaces as they apply to IPv6? A node is any device that implements IPv6. It can be a router, which is a device that forwards packets that aren't directed specifically to it, or a host, which is a node that doesn't forward packets. An interface is the connection to a transmission medium through which IPv6 packets are sent. Mike: How about some more IPv6 terminology - can you discuss Links, Neighbors, Link MTUs, and Link Layer Addresses? A link is the medium over which IPv6 is carried. Neighbors are nodes that are connected to the same link. A link maximum transmission unit (MTU) is the maximum packet size that can be carried over a given link medium, and is expressed in octets. A Link Layer address is the "physical" address of an interface, such as media access control (MAC) addresses for Ethernet links. Mike: Can you give a brief ouline in address syntax? IPv4 addresses are represented in dotted-decimal format. This 32-bit address is divided along 8-bit boundaries. Each set of 8 bits is converted to its decimal equivalent and separated by periods. For IPv6, the 128-bit address is divided along 16-bit boundaries, and each 16-bit block is converted to a 4-digit hexadecimal number and separated by colons. The resulting representation is called colon-hexadecimal. The following is an IPv6 address in binary form: 00100001110110100000000011010011000000000000000000101111001110110000001010101010000000001111111111111110001010001001110001011010 The 128-bit address is divided along 16-bit boundaries: 0010000111011010  0000000011010011   0000000000000000   0010111100111011  0000001010101010   0000000011111111   1111111000101000  1001110001011010    Each 16-bit block is converted to hexadecimal and delimited with colons. The result is: 21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A IPv6 representation can be further simplified by removing the leading zeros within each 16-bit block. However, each block must have at least a single digit. With leading zero suppression, the address representation becomes: 21DA:D3:0:2F3B:2AA:FF:FE28:9C5A Mike: I know there are lost of zeros in IPv6 addresses - can you discribe zero compression notation? Some types of addresses contain long sequences of zeros. To further simplify the representation of IPv6 addresses, a contiguous sequence of 16-bit blocks set to 0 in the colon hexadecimal format can be compressed to “::?, known as double-colon. For example, the link-local address of FE80:0:0:0:2AA:FF:FE9A:4CA2 can be compressed to FE80::2AA:FF:FE9A:4CA2. The multicast address FF02:0:0:0:0:0:0:2 can be compressed to FF02::2. Zero compression can only be used to compress a single contiguous series of 16-bit blocks expressed in colon hexadecimal notation. You cannot use zero compression to include part of a 16-bit block. For example, you cannot express FF02:30:0:0:0:0:0:5 as FF02:3::5. The correct representation is FF02:30::5. To determine how many 0 bits are represented by the “::?, you can count the number of blocks in the compressed address, subtract this number from 8, and then multiply the result by 16. For example, in the address FF02::2, there are two blocks (the “FF02? block and the “2? block.) The number of bits expressed by the “::? is 96 (96 = (8 – 2)(16). Zero compression can only be used once in a given address. Otherwise, you could not determine the number of 0 bits represented by each instance of “::?. Mike: IPv4 addresses use subnet masks - do IPv6 addresses? No - a subnet mask is not used for IPv6. Something called prefix length notation is supported. The prefix is the part of the address that indicates the bits that have fixed values or are the bits of the network identifier. Prefixes for IPv6 subnet identifiers, routes, and address ranges are expressed in the same way as Classless Inter-Domain Routing (CIDR) notation for IPv4. An IPv6 prefix is written in address/prefix-length notation. For example, 21DA:D3::/48 is a route prefix and 21DA:D3:0:2F3B::/64 is a subnet prefix. Mike: I know there are three basic types of IPv6 addresses - can you give a brief description of each? 1. Unicast – packet sent to a particular interface A unicast address identifies a single interface within the scope of the type of unicast address. With the appropriate unicast routing topology, packets addressed to a unicast address are delivered to a single interface. To accommodate load-balancing systems, RFC 2373 allows for multiple interfaces to use the same address as long as they appear as a single interface to the IPv6 implementation on the host. 2. Multicast - packet sent to a set of interfaces, typically encompassing multiple nodes A multicast address identifies multiple interfaces. With the appropriate multicast routing topology, packets addressed to a multicast address are delivered to all interfaces that are identified by the address. 3. Anycast – while identifying multiple interfaces (and typically multiple nodes) is sent only to the interface that is determined to be “nearest? to the sender. An anycast address identifies multiple interfaces. With the appropriate routing topology, packets addressed to an anycast address are delivered to a single interface, the nearest interface that is identified by the address. The “nearest? interface is defined as being closest in terms of routing distance. A multicast address is used for one-to-many communication, with delivery to multiple interfaces. An anycast address is used for one-to-one-of-many communication, with delivery to a single interface. In all cases, IPv6 addresses identify interfaces, not nodes. A node is identified by any unicast address assigned to one of its interfaces. Mike: What about broadcasting? RFC 2373 does not define a broadcast address. All types of IPv4 broadcast addressing are performed in IPv6 using multicast addresses. For example, the subnet and limited broadcast addresses from IPv4 are replaced with the link-local scope all-nodes multicast address of FF02::1. Mike: What about special addresses? The following are special IPv6 addresses: Unspecified Address The unspecified address (0:0:0:0:0:0:0:0 or ::) is only used to indicate the absence of an address. It is equivalent to the IPv4 unspecified address of 0.0.0.0. The unspecified address is typically used as a source address for packets attempting to verify the uniqueness of a tentative address. The unspecified address is never assigned to an interface or used as a destination address. Loopback Address The loopback address (0:0:0:0:0:0:0:1 or ::1) is used to identify a loopback interface, enabling a node to send packets to itself. It is equivalent to the IPv4 loopback address of 127.0.0.1. Packets addressed to the loopback address must never be sent on a link or forwarded by an IPv6 router. Mike: How is DNS handled? Enhancements to the Domain Name System (DNS) for IPv6 are described in RFC 1886 and consist of the following new elements: Host address (AAAA) resource record IP6.ARPA domain for reverse queries Note:  According to RFC 3152, Internet Engineering Task Force (IETF) consensus has been reached that the IP6.ARPA domain be used, instead of IP6.INT as defined in RFC 1886. The IP6.ARPA domain is the domain used by IPv6 for Windows Server 2003. The Host Address (AAAA) Resource Record: A new DNS resource record type, AAAA (called “quad A?), is used for resolving a fully qualified domain name to an IPv6 address. It is comparable to the host address (A) resource record used with IPv4. The resource record type is named AAAA (Type value of 28) because 128-bit IPv6 addresses are four times as large as 32-bit IPv4 addresses. The following is an example of a AAAA resource record:         host1.microsoft.com    IN    AAAA   FEC0::2AA:FF:FE3F:2A1C A host must specify either a AAAA query or a general query for a specific host name in order to receive IPv6 address resolution data in the DNS query answer sections. The IP6.ARPA Domain The IP6.ARPA domain has been created for IPv6 reverse queries. Also called pointer queries, reverse queries determine a host name based on the IP address. To create the namespace for reverse queries, each hexadecimal digit in the fully expressed 32-digit IPv6 address becomes a separate level in inverse order in the reverse domain hierarchy. For example, the reverse lookup domain name for the address FEC0::2AA:FF:FE3F:2A1C (fully expressed as FEC0:0000:0000:0000:02AA: 00FF:FE3F:2A1C) is: C.1.A.2.F.3.E.F.F.F.0.0.A.A.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.IP6.ARPA. The DNS support described in RFC 1886 represents a simple way to both map host names to IPv6 addresses and provide reverse name resolution. Mike: Can you discuss transition from IPv4 to IPv6? Mechanisms for transitioning from IPv4 to IPv6 are defined in RFC 1933. The primary goal in the transition process is a successful coexistence of the two protocol versions until such time as IPv4 can be retired if, indeed, it's ever completely decommissioned. Transition plans fall into two primary categories: dual-stack implementation, and IPv6 over IPv4 tunneling. More Info Mechanisms for transitioning from IPv4 to IPv6 are defined in RFC 1933. There are two primary methods. Dual Stack Implementation The simplest method for providing IPv6 functionality allows the two IP versions to be implemented as a dual stack on each node. Nodes using the dual stack can communicate via either stack. While dual-stack nodes can use IPv6 and IPv4 addresses that are related to each other, this isn't a requirement of the implementation, so the two addresses can be totally disparate. These nodes also can perform tunneling of IPv6 over IPv4. Because each stack is fully functional, the nodes can configure their IPv6 addresses via stateless autoconfiguration or DHCP for IPv6, while configuring their IPv4 addresses via any of the current configuration methods. IPv6 Over IPv4 Tunneling The second method for implementing IPv6 in an IPv4 environment is by tunneling IPv6 packets within IPv4 packets. These nodes can map an IPv4 address into an IPv4-compatible IPv6 address, preceding the IPv4 address with a 96-bit "0:0:0:0:0:0" prefix. Routers on a network don't need to immediately be IPv6-enabled if this approach is used, but Domain Name System (DNS) servers on a mixed-version network must be capable of supporting both versions of the protocol. To help achieve this goal, a new record type, "AAAA," has been defined for IPv6 addresses. Because Windows 2000 DNS servers implement this record type as well as the IPv4 "A" record, IPv6 can be easily implemented in a Windows 2000 environment. Mike: we've only touched on some of the IPv6 details - where can people get more information? I'm hoping to run a session at our summer conference July 28 - 31 in Austin, TX - we've currently got faculty fellowships available to cover the cost of the conference. See www.nctt.org for details. References - Content for this academic podcast from Microsoft sources: All Linked Documents at Microsoft Internet Protocol Version 6 (note: excellent and free online resources): http://technet.microsoft.com/en-us/network/bb530961.aspx Understanding IPv6, Joseph Davies, Microsoft Press, 2002 ISBN: 0-7356-1245-5 Sample Chapter at: http://www.microsoft.com/mspress/books/sampchap/4883.asp#SampleChapter

Paul Vixie has been contributing to Internet protocols and UNIX systems as a protocol designer and software architect since 1980. Early in his career, he developed and introduced sends, proxynet, rtty, cron and other lesser-known tools. Today, Paul is considered the primary modern author and technical architect of BINDv8 the Berkeley Internet Name Domain Version 8, the open source reference implementation of the Domain Name System (DNS). He formed the Internet Software Consortium (ISC) in 1994, and now acts as Chairman of its Board of Directors. The ISC reflects Paul's commitment to developing and maintaining production quality open source reference implementations of core Internet protocols. More recently, Paul cofounded MAPS LLC (Mail Abuse Prevention System), a California nonprofit company established in 1998 with the goal of hosting the RBL (Realtime Blackhole List) and stopping the Internet's email system from being abused by spammers. Vixie is currently the Chief Technology Officer of Metromedia Fiber Network Inc (MFNX.O). Along with Frederick Avolio, Paul co-wrote "Sendmail: Theory and Practice" (Digital Press, 1995). He has authored or co-authored several RFCs, including a Best Current Practice document on "Classless IN-ADDR.ARPA Delegation" (BCP 20). He is also responsible for overseeing the operation of F.root-servers.net, one of the thirteen Internet root domain name servers.

Paul Vixie has been contributing to Internet protocols and UNIX systems as a protocol designer and software architect since 1980. Early in his career, he developed and introduced sends, proxynet, rtty, cron and other lesser-known tools. Today, Paul is considered the primary modern author and technical architect of BINDv8 the Berkeley Internet Name Domain Version 8, the open source reference implementation of the Domain Name System (DNS). He formed the Internet Software Consortium (ISC) in 1994, and now acts as Chairman of its Board of Directors. The ISC reflects Paul's commitment to developing and maintaining production quality open source reference implementations of core Internet protocols. More recently, Paul cofounded MAPS LLC (Mail Abuse Prevention System), a California nonprofit company established in 1998 with the goal of hosting the RBL (Realtime Blackhole List) and stopping the Internet's email system from being abused by spammers. Vixie is currently the Chief Technology Officer of Metromedia Fiber Network Inc (MFNX.O). Along with Frederick Avolio, Paul co-wrote "Sendmail: Theory and Practice" (Digital Press, 1995). He has authored or co-authored several RFCs, including a Best Current Practice document on "Classless IN-ADDR.ARPA Delegation" (BCP 20). He is also responsible for overseeing the operation of F.root-servers.net, one of the thirteen Internet root domain name servers.

This talk considers security challenges facing the Internet's Domain Name System (DNS). The DNS is one of the most widely used and least secure Internet systems. Viirtually every Internet application relies on the DNS to convert names into IP addresses and the DNS provides a wide range of other critical mappings such as identifying mail servers and locate services. But despite its importance, the original DNS design gave very little thought to security and a variety of misdirection and denial of service attacks are possible. For example, a web browser relies on the DNS to convert www.purdue.edu into an IP address. The DNS supplies the web browser with an IP address (more precisely an "A" resource record set) such as 129.82.100.64 (is this address correct?). If this address is wrong, the browser will be directed to the wrong site. If the DNS fails to return a response, the browser will not be able to load the desired web page. Currently, both the operational and research communities are making considerable efforts to improve DNS security. After nearly a decade of development, the IETF has standardized DNS Security Extensions that add public key authentication into the DNS. The hierarchical structure of the DNS is leveraged to authenticate public keys, keys can be managed offline, and the signatures allow a resolver to authenticate a response. However several open issues remain, including key revocation, support for dynamic updates, resolver security policies, incremental deployment, and commercial challenges. The DNS Security Extension enable a number of new techniques, but basic problems on denial of service remain. The research community has largely focused on denial of service attacks against critical top level servers could potentially cause considerable damage to the DNS service. This has led to proposals for replacing the DNS tree with a distributed hash table attacking a few critical top level servers. This talk will argues that, despite some major flaws, the DNS Security Extensions provide the necessary tools to build a robust and secure DNS. By using these tools appropriately, a wholesale replacement of the DNS system by other approaches can and should be avoided. About the speaker:

This talk considers security challenges facing the Internet's Domain Name System (DNS). The DNS is one of the most widely used and least secure Internet systems. Viirtually every Internet application relies on the DNS to convert names into IP addresses and the DNS provides a wide range of other critical mappings such as identifying mail servers and locate services. But despite its importance, the original DNS design gave very little thought to security and a variety of misdirection and denial of service attacks are possible. For example, a web browser relies on the DNS to convert www.purdue.edu into an IP address. The DNS supplies the web browser with an IP address (more precisely an "A" resource record set) such as 129.82.100.64 (is this address correct?). If this address is wrong, the browser will be directed to the wrong site. If the DNS fails to return a response, the browser will not be able to load the desired web page. Currently, both the operational and research communities are making considerable efforts to improve DNS security. After nearly a decade of development, the IETF has standardized DNS Security Extensions that add public key authentication into the DNS. The hierarchical structure of the DNS is leveraged to authenticate public keys, keys can be managed offline, and the signatures allow a resolver to authenticate a response. However several open issues remain, including key revocation, support for dynamic updates, resolver security policies, incremental deployment, and commercial challenges. The DNS Security Extension enable a number of new techniques, but basic problems on denial of service remain. The research community has largely focused on denial of service attacks against critical top level servers could potentially cause considerable damage to the DNS service. This has led to proposals for replacing the DNS tree with a distributed hash table attacking a few critical top level servers. This talk will argues that, despite some major flaws, the DNS Security Extensions provide the necessary tools to build a robust and secure DNS. By using these tools appropriately, a wholesale replacement of the DNS system by other approaches can and should be avoided.