A Crash Course: DNS & BIND

Total Page:16

File Type:pdf, Size:1020Kb

A Crash Course: DNS & BIND A Crash Course: DNS & BIND If you are familiar with the DNS and operating BIND, then this appendix is probably irrelevant to you. But if you have never set up a name server before, doing so may be a daunting task. To get started, this section provides the absolutely necessary basics, so you might get away without reading some more advanced documentation, like Albitz’ and Liu’s “DNS and BIND” [2] or the “BIND 9 Administrator Reference Manual” [73] for now. To keep things simple, we ignore IPv6 and just focus on IPv4 addresses. A.1 Domain Name System (DNS) Basics The domain name system (DNS) takes a domain name and uses it to look up resource records (RRs) associated with that name. Each RR consists of a domain name,arecord type,arecord class which is always IN for “Internet” for our purposes, a time to live (TTL) that specifies how long the entry may be cached, and finally the associated data. If we want to surf “www.example.com”, our web server uses the resolver li- brary to send a forward query to a name server, asking for the “type A” records associated with the domain name “www.example.com.”tolearnaboutthe IP address of the web server with that name. The web server, when accepting the connection from the web browser, may use the IP address used by the browser to do a reverse lookup, making the resolver turn the IP address into a funny-looking domain name that can be queried for the associated “type PTR” record. This record should contain the host name of the machine we run the web browser on. To make the DNS scalable, names are structured hierarchically. The root domain,“.” contains all names. Most importantly, it contains the top-level domains,like“net.”or“org.”. These domains contain the second-level domains like “benedikt-stockebrand.net.” or the one we use here for our demonstration purposes, “example.com.”. Within these domains we may have additional subdomains as well as RRs that actually contain data. 350 A Crash Course: DNS & BIND Reverse lookups convert IP addresses into domain names in the pseudo do- main “in-addr.arpa.” by reverting the order of address bytes, thus turning 192.0.2.80 into “80.2.9.192.in-addr-arpa.”. If you look closely, you see that a domain name always ends in a trailing dot.Thisshowsthatitisafully qualified domain name (FQDN )andisrooted in the root zone. A name without a trailing dot is an unqualified domain name and a default domain name needs to be appended to form the FQDN. If we configure our system to use “example.com.” as the default domain, then we can use “www” as an abbreviation for “www.example.com.”. To make the DNS scale, a domain may delegate a zone to another name server or set of servers. A zone is like a subdomain, except that it doesn’t contain the zones it delegates itself. The root servers delegate the “com.” zone to some other servers, so “example.com.” is still within the root domain, but not within the root zone. Every RR belongs to a single zone but to an entire series of domains. (Later on we’ll learn about the two exceptions from this rule necessary to delegate a zone.) To make the DNS scale to Internet proportions it is necessary to main- tain forward and reverse zones independently of each other. This is a major nuisance in many cases but can’t be helped. For every zone there is a primary name server (sometimes called the mas- ter for historical reasons) and a set of secondary name servers (or slaves). The zone data is actively maintained on the primary and from there distributed to the secondaries. These servers are called authoritative name servers because they are assumed to hold correct data at all times. In contrast to that, name servers are called non-authoritative if they only provide cached data for the zone in question. They have either queried an authoritative name server themselves or asked another “upstream” caching name server called a forwarder. Normally, programs always use a caching name server, which builds up a rich cache that takes a lot of load from the authoritative servers while providing for fast DNS lookups. All name servers, even authoritative ones, usually also operate as a caching server. A.2 The BIND Name Server The standard name server software used with Unix is called BIND, short for Berkeley Internet name domain. It consists of the actual name server daemon called named and a set of additional tools. A.2.1 Installation To set up a name server, we may first need to install some additional packages: A.2 The BIND Name Server 351 Debian Sarge The name server proper is in package bind9 and some es- sential tools like dig in dnsutils. FreeBSD 6.1 Here the name server is part of the core system, so no ad- ditional packages are necessary. But we need to build some of the default configuration by doing # cd /etc/namedb # sh make-localhost example.com to make our name server usable. Solaris 10 The name server service manifest and the name server proper are in the packages SUNWbindr and SUNWbind. Depending on the subrelease and patchlevel, we may also need to install patch 119783 (SPARC) or 119784 (x86) and reboot the machine to fix a bug1. 136 If you want to use an existing BIND installation, make sure the version of BIND is at least 9.2.3 or up; otherwise you will run into problems later on. A.2.2 Base Configuration The named daemon maintains its configuration in a file called named.conf. Authoritative name servers store the data of their zones in separate zone files. Unfortunately, different Unixen have not only complex but also widely differing default configurations. The named.conf file may reside in /etc (So- laris 10), /etc/bind (Debian Sarge), /etc/namedb (FreeBSD 6.1) or wherever else an installation chooses to put it. Additionally, the name server daemon named is sometimes run in a chroot environment, adding more problems: The configuration may actually reside in the chroot environment instead of /etc while a symlink in /etc points to the actual location, usually somewhere within /var—this can prove disastrous if our backup doesn’t include these files. In other cases, the boot scripts copy the configuration files from /etc to the chroot environment whenever we restart named—as a result, they may happily overwrite any changes we applied there directly, and restarting the named directly will keep it running with the old configuration. This leaves you a difficult choice: Either abandon all the standard configu- ration and start from scratch or adapt the default configuration accordingly. If you want to start from scratch, a complete albeit minimal configuration may look like this: named.conf options { directory "/var/named/zonedata"; pid-file "/var/run/named.pid"; allow-query { "any"; }; }; 1 On an unpatched system a reboot will disable the DNS service again. 352 A Crash Course: DNS & BIND It tells the name server that all the zone data files are kept in the directory /var/named/zonedata, to keep the PID file in a standard place and to allow queries from any address. At this point the named worksasacaching-only server that is not authoritative for any zones. Debian Sarge The configuration options for named are kept in a sepa- rate file /etc/bind/named.conf.options while the zone configurations go to /etc/bind/named.conf.local. You need to adapt the following examples accordingly. FreeBSD 6.1 The named.conf fileislocatedin/etc/namedb/. Solaris 10 The packages don’t include a default configuration, so we create afile/etc/named.conf with the minimal configuration shown above and a directory /var/named/zonedata to hold the zone files. 137 A.2.3 Forwarder Configuration and Fake Root Zones Next we need to tell the name server how to deal with requests for data that it isn’t authoritative for. It is easiest to ask our provider for the IP address of their DNS server and add another line to the options section of named.conf that reads something like named.conf options { [...] forwarders { 192.0.2.1; }; [...] } given that the IP address of our provider’s DNS server is 192.0.2.1.Theal- ternative approach, using a hints file that contains the addresses of root name servers, is beyond the scope of this crash course—see the BIND literature, for example Albitz and Liu [2, pages 67–69] if you want to do this. In an isolated test network without Internet connectivity this doesn’t work, because we can’t reach a forwarder or root name server. Section 5.2.3 has a solution to deal with this problem: Setting up a fake server for the root zone will ensure that all requests will be served without waiting for a timeout, but possibly with a negative result. A.2.4 Starting the Name Server Nowweenablethenamed daemon. Debian Sarge The bind9 package automatically installs the appropriate boot scripts; we just run /etc/init.d/bind9 start or reboot our machine. A.2 The BIND Name Server 353 FreeBSD 6.1 We add a line /etc/rc.conf named_enable=YES to /etc/rc.conf andeitherrebootorrun/etc/rc.d/named start by hand. Solaris 10 We run the command svcadm enable dns/server. 138 At this point we should have a running name server. Checking that it works is reasonably straightforward: Check with ps that the named process is running.
Recommended publications
  • Oracle Berkeley DB Installation and Build Guide Release 18.1
    Oracle Berkeley DB Installation and Build Guide Release 18.1 Library Version 18.1.32 Legal Notice Copyright © 2002 - 2019 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. Berkeley DB, and Sleepycat are trademarks or registered trademarks of Oracle. All rights to these marks are reserved. No third- party use is permitted without the express prior written consent of Oracle. Other names may be trademarks of their respective owners. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.
    [Show full text]
  • Unbound: a New Secure and High Performance Open Source DNS Server
    New Open Source DNS Server Released Today Unbound – A Secure, High-Performance Alternative to BIND – Makes its Debut within Open Source Community Amsterdam, The Netherlands and Mountain View, CA – May 20, 2008 – Unbound – a new open source alternative to the BIND domain name system (DNS) server– makes its worldwide debut today with the worldwide public release of Unbound 1.0 at http://unbound.net. Released to open source developers by NLnet Labs, VeriSign, Inc. (NASDAQ: VRSN), Nominet, and Kirei, Unbound is a validating, recursive, and caching DNS server designed as a high- performance alternative for BIND (Berkeley Internet Name Domain). Unbound will be supported by NLnet Labs. An essential component of the Internet, the DNS ties domain names (such as www.verisign.com) to the IP addresses and other information that Web browsers need to access and interact with specific sites. Though it is unknown to the vast majority of Web users, DNS is at the heart of a range of Internet-based services beyond Web browsing, including email, messaging and Voice Over Internet Protocol (VOIP) telecommunications. Although BIND has been the de facto choice for DNS servers since the 1980s, a desire to seek an alternative server that excels in security, performance and ease of use prompted an effort to develop an open source DNS implementation. Unbound is the result of that effort. Mostly deployed by ISPs and enterprise users, Unbound will also be available for embedding in customer devices, such as dedicated DNS appliances and ADSL modems. By making Unbound code available to open source developers, its originators hope to enable rapid development of features that have not traditionally been associated with DNS.
    [Show full text]
  • Stateless DNS
    Technical Report KN{2014{DiSy{004 Distributed System Laboratory Stateless DNS Daniel Kaiser, Matthias Fratz, Marcel Waldvogel, Valentin Dietrich, Holger Strittmatter Distributed Systems Laboratory Department of Computer and Information Science University of Konstanz { Germany Konstanzer Online-Publikations-System (KOPS) URL: http://nbn-resolving.de/urn:nbn:de:bsz:352-0-267760 Abstract. Several network applications, like service discovery, file dis- covery in P2P networks, distributed hash tables, and distributed caches, use or would benefit from distributed key value stores. The Domain Name System (DNS) is a key value store which has a huge infrastructure and is accessible from almost everywhere. Nevertheless storing information in this database makes it necessary to be authoritative for a domain or to be \registered" with a domain, e.g. via DynDNS, to be allowed to store and update resource records using nsupdate . Applications like the ones listed above would greatly benefit from a configurationless approach, giving users a much more convenient experience. In this report we describe a technique we call Stateless DNS, which allows to store data in the cache of the local DNS server. It works without any infrastructure updates; it just needs our very simple, configurationless echo DNS server that can parse special queries containing information desired to be stored, process this information, and generate DNS answers in a way that the DNS cache that was asked the special query will store the desired information. Because all this happens in the authority zone of our echo DNS server, we do not cause cache poisoning. Our tests show that Stateless DNS works with a huge number of public DNS servers.
    [Show full text]
  • Internet Systems Consortium, Inc
    BIND 9 Administrator Reference Manual I S C Copyright c 2004, 2005, 2006, 2007, 2008, 2009, 2010 Internet Systems Consortium, Inc. (”ISC”) Copyright c 2000, 2001, 2002, 2003 Internet Software Consortium. Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED ”AS IS” AND ISC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. 2 Contents 1 Introduction 9 1.1 Scope of Document . 9 1.2 Organization of This Document . 9 1.3 Conventions Used in This Document . 9 1.4 The Domain Name System (DNS) . 10 1.4.1 DNS Fundamentals . 10 1.4.2 Domains and Domain Names . 10 1.4.3 Zones . 10 1.4.4 Authoritative Name Servers . 11 1.4.4.1 The Primary Master . 11 1.4.4.2 Slave Servers . 11 1.4.4.3 Stealth Servers . 11 1.4.5 Caching Name Servers . 12 1.4.5.1 Forwarding . 12 1.4.6 Name Servers in Multiple Roles . 12 2 BIND Resource Requirements 13 2.1 Hardware requirements . 13 2.2 CPU Requirements . 13 2.3 Memory Requirements .
    [Show full text]
  • Bind 9 Linux 3.19, Microsoft Windows Server 2008 Integration Guide: Bind 9
    Integration Guide Bind 9 Linux 3.19, Microsoft Windows Server 2008 Integration Guide: Bind 9 Imprint copyright 2016 Utimaco IS GmbH Germanusstrasse 4 D-52080 Aachen Germany phone +49 (0)241 / 1696-200 fax +49 (0)241 / 1696-199 web http://hsm.utimaco.com email [email protected] document version 1.2.1 date January 2016 author System Engineering HSM document no. SGCS_IG_BIND9 all rights reserved No part of this documentation may be reproduced in any form (printing, photocopy or according to any other process) without the written approval of Utimaco IS GmbH or be processed, reproduced or distributed using electronic systems. Utimaco IS GmbH reserves the right to modify or amend the documentation at any time without prior notice. Utimaco IS GmbH assumes no liability for typographical errors and damages incurred due to them. All trademarks and registered trademarks are the property of their respective owners. Contents 1 Introduction 4 1.1 Concepts ............................................. 4 2 Requirements 5 2.1 Supported Operating Systems ................................ 5 3 Installation 6 3.1 Install CryptoServer Hardware ................................. 6 3.2 Install CryptoServer Software ................................. 6 4 Procedures 7 4.1 Configure PKCS#11 Environment ............................... 7 4.1.1 Linux ........................................... 7 4.1.2 Microsoft Windows .................................. 7 4.1.3 Adjust Configuration File ............................... 7 4.2 Test PKCS#11 Environment .................................. 8 4.3 Patch and Build OpenSSL ................................... 9 4.3.1 Linux ........................................... 9 4.3.2 Microsoft Windows .................................. 10 4.4 Install BIND Domain Name Server .............................. 12 4.4.1 Linux ........................................... 12 4.4.2 Microsoft Windows .................................. 12 5 Generate Keys and Sign a Domain Zone 14 5.1 ReSigning Domain Zones ..................................
    [Show full text]
  • Getting Started with Berkeley DB Java Edition
    Oracle Berkeley DB, Java Edition Getting Started with Berkeley DB Java Edition 12c Release 2 Library Version 12.2.7.5 Legal Notice Copyright © 2002 - 2017 Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. Berkeley DB, Berkeley DB Java Edition and Sleepycat are trademarks or registered trademarks of Oracle. All rights to these marks are reserved. No third-party use is permitted without the express prior written consent of Oracle. Other names may be trademarks of their respective owners. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.
    [Show full text]
  • Analysis of DNS Resolver Performance Measurements Author
    Master in System and Network Engineering Analysis of DNS Resolver Performance Measurements Supervisors: Author: Yuri Schaeffer Hamza Boulakhrif [email protected] [email protected] Willem Toorop [email protected] July 13, 2015 Abstract The Domain Name System (DNS) is an essential building block of the Internet. Applica- tions depend on it in order to operate properly. Therefore DNS resolvers are required to perform well, and do whatever they can to provide an answer to a query. In this paper a methodology is devised to measure the performance of the Unbound, BIND, and PowerDNS resolvers. Measurements of these resolvers is required to be objective and not biased. Analysis is conducted on these performance measurements, where the implementations are compared to each other. Corner cases have also been identified and analysed. Acknowledgement I would like to thank NLnet Labs for providing this interesting Research Project. Also the support they provided throughout this project is really appreciated. Especially Willem Toorop and Yuri Schaeffer who answered all of my questions and guided me through this project. Thanks go also to Wouter Wijngaards who answered my questions related to DNS resolvers. The performed measurements during this project were carried out from the SNE lab, at the University of Amsterdam. I would also like to thank Harm Dermois for providing his server in the lab to perform these measurements. Special thanks also go to the SNE staff for their support and guidance. This does not only concern this project but the entire study. Hamza Boulakhrif 1 Contents 1 Introduction 3 1.1 Related Work . .3 1.2 Research Questions .
    [Show full text]
  • Working with Oracle® Solaris 11.4 Directory and Naming Services: LDAP
    ® Working With Oracle Solaris 11.4 Directory and Naming Services: LDAP Part No: E61012 November 2020 Working With Oracle Solaris 11.4 Directory and Naming Services: LDAP Part No: E61012 Copyright © 2002, 2020, Oracle and/or its affiliates. License Restrictions Warranty/Consequential Damages Disclaimer This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. Warranty Disclaimer The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. Restricted Rights Notice If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users
    [Show full text]
  • BIND 9 the Past, the Present and the Future Ondřej Surý @ ISC FOSDEM 2018, Brussels BIND 9.0: the Past
    BIND 9 The Past, The Present and The Future Ondřej Surý @ ISC FOSDEM 2018, Brussels BIND 9.0: The Past • First released in 2000 • Other things from 2000: • gcc 2.95.2 • Linux kernel 2.4.0 • GNOME 1.2 • Qt 2.0 • Window 2000 • First camera phone • Playstation 2 launched • New century started (only in pop- culture and US) Photo by Jacob Wixom on Unsplash BIND 9 Past Releases BIND 9.12: The Present • NSEC Aggressive Use • Serve Stale (TTL Stretching) • Response Policy Interface • Major Refactoring [1] • Speedup factor: 1.25-6 • CDS/CDNSKEY tools • EDDSA Support (when available in OpenSSL) 1. https://www.isc.org/blogs/evan-hunt-presented-the-bind-9-12-refactoring-at-dns-oarc/ Photo by Robert Zunikoff on Unsplash BIND 9: The Future • Open Development • Faster Release Cycle • Reduce Supported Platforms • New Features • More Refactoring Photo by Tom Barrett on Unsplash Open Development • Open (By Default) Issue Tracker • Public Merge Requests • Public Wiki • Public Continuous Integration • (Future) Public Web Forum to discuss BIND and DNS Photo by Roman Kraft on Unsplash ISC GitLab • Work In Progress • Self-hosted Instance • https://gitlab.isc.org/isc-projects/bind9 Faster Release Cycle • Odd Numbers — Development Release • 9.13.x, 9.15.x, 9.17.x • Releases as we go • Best Effort Support • Even Numbers — Stable Release • When Development Release stabilise • 9.13.<last> → 9.14.0 • Supported until next Stable Release = ~ 1 year • Every Second Stable Release — Extended Support Version • Supported until next ESV Release with overlap = 4 years BIND
    [Show full text]
  • Writing Exploit-Resistant Code with Openbsd Lawrence Teo Lteo Openbsd.Org @Lteo
    Writing Exploit-Resistant Code with OpenBSD Lawrence Teo lteo openbsd.org @lteo Slides and references at: https://lteo.net/carolinacon15 CarolinaCon 15 - Charlotte, NC - April 27, 2019 A question Innovation’s Black Hole Security vulnerabilities Image Credit: EHT Collaboration https://www.eso.org/public/images/eso1907a/ What is OpenBSD? • Free, multi-platform UNIX-liKe operating system • Founded by Theo de Raadt in 1995 • Secure by default • A research operating system • Two releases per year • You’re very liKely using OpenBSD code everyday • OpenSSH • LibreSSL • tmux • More: openbsd.org/innovations.html • Coolest mascot ever whoami • OpenBSD developer since 2012 • Primarily areas related to networking • PF, networK stacK, libpcap, tcpdump, etc. • Userland stuff, ports, man pages, etc • Co-founder, Calyptix Security • Shipping thousands of OpenBSD-based firewalls from Charlotte since 2006! • Ph.D. from UNC Charlotte (2006) • Research area: Info sharing for intrusion detection Auditing Software vulnerabilities How OpenBSD attacks the software vulnerability problem (my view) Auditing Exploit Software Mitigation vulnerabilities Techniques How OpenBSD attacks the software vulnerability problem (my view) Auditing Exploit Software Mitigation vulnerabilities Techniques Rigorous Development Process How OpenBSD attacks the software vulnerability problem (my view) Licensing Auditing Exploit Software Mitigation vulnerabilities Techniques Rigorous Development Process How OpenBSD attacks the software vulnerability problem (my view) Licensing Education
    [Show full text]
  • Study of Packet Level UDP Performance of NAT44, NAT64 and Ipv6 Using Iperf in the Context of Ipv6 Migration
    Study of packet level UDP performance of NAT44, NAT64 and IPv6 using iperf in the context of IPv6 migration Vitruvius John D. Barayuga William Emmanuel S. Yu Institute of Computing Studies Department of Information Systems and Computer Science Ilocos Sur Polytechnic State College Ateneo de Manila Univeristy Santa Maria, Ilocos Sur, Philippines Quezon City [email protected] [email protected] Abstract— The Internet Assigned Number Authority (IANA) The initial design specification did not take into account the allocated the last of the available /8's of the IPv4 address space to need for the protocol to handle video-on-demand services, or the Regional Internet Registries (RIR's) on February 2011. It other types of large scale data, also with the advent of mobile could not be denied that IPv6 is the Internet of the next communications, set top boxes that have internet access taking generation, however its utilization and implementation in a wide presence in the home, each device requires an IP address, each scale had brought hesitation to the users since it will take time device requires an IP address. and there are concerns that need to be explored in the future. However, the need for a new technology is not paramount; Hence, this paper will lead the way for the acceptance of Internet the current 30-year-old technology has been modified to Protocol version 6 (IPv6) migration in the Philippines using a coincide with new ideas and ways of working. For a similar Network Address Translation (NAT) that there is an sustainable network to be developed and evolve over the next apparent means to be taken into consideration and NAT IPv6 to IPv4 (NAT64) can be a good choice for computer networks with few years a seamless migration over to IPv6 needs to be made.
    [Show full text]
  • Fortios™ Handbook - Ipv6
    IPv6 FortiOS™ Handbook - IPv6 5.6.3 FORTINET DOCUMENT LIBRARY http://docs.fortinet.com FORTINET VIDEO GUIDE http://video.fortinet.com FORTINET BLOG https://blog.fortinet.com CUSTOMER SERVICE & SUPPORT https://support.fortinet.com http://cookbook.fortinet.com/how-to-work-with-fortinet-support/ FORTIGATE COOKBOOK http://cookbook.fortinet.com FORTINET TRAINING SERVICES http://www.fortinet.com/training FORTIGUARD CENTER http://www.fortiguard.com FORTICAST http://forticast.fortinet.com END USER LICENSE AGREEMENT http://www.fortinet.com/doc/legal/EULA.pdf FORTINET PRIVACY POLICY https://www.fortinet.com/corporate/about-us/privacy.html FEEDBACK Email: [email protected] Wednesday, January 24, 2018 FortiOS™ Handbook - IPv6 01-560-112805-20180124 TABLE OF CONTENTS Change Log 5 Introduction 6 IPv6 packet structure 7 Jumbograms and jumbo payloads 7 Fragmentation and reassembly 7 Benefits of IPv6 7 What's new for IPv6 in FortiOS 5.6 8 IPv6 (5.6.3) 8 IPv6 RADIUS support (402437, 439773) 8 Added support for IPv6 Fortisandbox (424290) (447153) 8 IPv6 captive portal support (435435) 8 FortiGate can reply to an anycast probe from the interface’s unicast address (308872) 8 Secure Neighbor Discovery (355946) 8 Add multicast-PMTU to allow FGT to send ICMPv6 Too Big Message (373396) 10 IPv6 Features 11 IPv6 policies 11 IPv6 policy routing 12 IPv6 security policies 13 IPv6 explicit web proxy 14 VIP64 15 IPv6 Network Address Translation 20 NAT64 and DNS64 (DNS proxy) 20 NAT66 23 NAT64 and NAT66 session failover 25 NAT46 25 ICMPv6 26 ICMPv6 Types and Codes
    [Show full text]