Instalojme fillimisht paketen e BIND:
Disa nga konfigurimet me te zakonshme jane :
Skedari i pare i konfigurimit eshte /etc/named.conf.
Me poshte eshte nje shembull i skedarit
Forward Zone File
Per te shtuan nje zone DNS ne BIND9, duke e kthyer ate ne nje Primary Master server, hapi i pare eshte editimi i
Me tej krijojme skedarin e databazes me rekordet e zones tone nen emrin
Duhet modifikuar skedari
Vendoset adresa IP e serverit DNS dhe root.example.com me adresen e email te administratorit te domain , por me "." ne vend te simbolit te zakonshem te email ".
Sqarime ne lidhje me permbajtjen e skedarit te zones:
Default TTL - Time To Live. $TTL percakton kohe baze te vlefshmerise te te gjithe rekordeve ne skedar, ne rast se ajo nuk percakothet ne menyre specifike per nje rekord. Njesia matese eshte ne sekonda.
Nje vlere a zakonshme mund te jete 86400 sekonda ose 24 ore. Kjo vlere percakton se per sa kohe do te reflektohet ndryshimi i nje rekordi ne serverat DNS neper interenet.
Dynamic DNS (DDNS) zakonisht perdor nje TTL te barabarte me 5 minutes, ose 300 sekonda.
SOA (Start Of Authority) tregon cili eshte serveri qe eshte pergjegjes per kete zone , qe do te thote se ky server eshte serveri autoritar per kete zone. Mund te kete vetem nje rekord SOA ne cdo skedar te dhenash te domain (db.DOMAIN).
Te shpjegojme cfare permban SOA:
emri i domain psh @ ose ict.local.
IN = Internet
SOA = Start of Authority
emri i serverit SOA (per shembull localhost ose myserver.ict.local.)
email i administratorit te domain per shembull admin.ict.local. ose root.localhost. qe do te interpretohen si email@example.com ose root@localhost
Me pas midis kllapave:
numri serial, qe tregon versionin e skedarit te te dhenave. Ky numer perdoret nga serveri sekondar i DNS per te kuptuar nese ka ndryshuar skedari i te dhenave qe nga hera e fundit qe ai eshte sinkronizuar?
refresh , i tregon serverit sekondar pas sa kohesh duhet te pyese serish serverin primar nese ka ndryshuar skedari i te dhenave
retry, i tregon serverit sekondar pas sa kohesh duhet te riprovoje nese nuk mundi qe te kontaktoje me serverin primar
expiry, i tregon serverit sekondar se pas sa kohesh qe nuk ka komunikuar me serverin primar te dhenat e tij jane te pavlefshme
Negative Cache TTL , i tregon klienteve DNS te cilet kane marre nje pergjigje negative per nje rekord nga serveri i DNS se sa kohe do ta mbajne mend kete pergjigje perpara se te pyesin serish serverin SoA)
Me poshte vazhdojme me rekordet e tjesa DNS
Eshte e mundur madje e rekomandueshme qe te shtohet gijthashtu nje zone reverse qe perkthen nga IP ne emra:
Tani krijoni skedarin db.192 :
Edhe ne zonen reverse duhet te kujdesemi per inkrementimin e Numrit Serial sa here qe modifikojme skedarin e zones. Per cdo rekord A te krijuar ne zonen forward ne db.example.com, eshte e nevojshme te krijojme nje rekord PTR ne skedarin e zones reverse db.192.
Pas modifikimit te zones reverse duhet gjithashtu restartuar sherbimi per te aplikuar ndryshimet :
Se pari, ne serverin Primary Master , duhet lejuar transferimi i zones .
Kjo behet duke shtuar opsionin
allow-transfer tek zonat Forward dhe Reverse ne
Vendosni IP e serverit Tuaj sekondar ne vend te IP 192.168.1.11 .
Restartoni named tek Primary Master:
Se dyti , tek Secondary Master, instaloni paketen named ne te njejten menyre si tek Primary.
Me pas editoni
Zevendesoni 192.168.1.10 me adresen IP te serverit tuaj Primary .
Restartoni sherbimin named tek Secondary Master:
Sjellja baze eshte qe permbajtja e skedarit
Me poshte eshte nje shembull i skedarit
Ne kete LAB ilustrohet instalimi dhe konfigurimi baze i nje serveri DNS
Instalimi i serverit DNS
Ne menyre qe te kapim sherbimin e
DNS Serverit nepermjet rrjetit duhet te ulim firewall.
When a DNS client needs to look up a name used in a program, it queries DNS servers to resolve the name. Each query message the client sends contains three pieces of information, specifying a question for the server to answer:
For example, the name specified could be the FQDN for a computer, such as "host-a.example.microsoft.com.", and the query type specified to look for an address (A) resource record by that name. Think of a DNS query as a client asking a server a two-part question, such as "Do you have any A resource records for a computer named 'hostname.example.microsoft.com.'?" When the client receives an answer from the server, it reads and interprets the answered A resource record, learning the IP address for the computer it asked for by name.
DNS queries resolve in a number of different ways. A client can sometimes answer a query locally using cached information obtained from a previous query. The DNS server can use its own cache of resource record information to answer a query. A DNS server can also query or contact other DNS servers on behalf of the requesting client to fully resolve the name, then send an answer back to the client. This process is known as recursion.
In addition, the client itself can attempt to contact additional DNS servers to resolve a name. When a client does so, it uses separate and additional nonrecursive queries based on referral answers from servers. This process is known as iteration.
In general, the DNS query process occurs in two parts:
Both of these processes are explained in more detail in the following sections.
The following figure shows an overview of the complete DNS query process.
As shown in the initial steps of the query process, a DNS domain name is used in a program on the local computer. The request is then passed to the DNS Client service for resolution using locally cached information. If the queried name can be resolved, the query is answered and the process is completed.
The local resolver cache can include name information obtained from two possible sources:
If the query does not match an entry in the cache, the resolution process continues with the client querying a DNS server to resolve the name.
As indicated in the previous figure, the client queries a preferred DNS server. The actual server used during the initial client/server query part of the process is selected from a global list. For more information about how this global list is compiled and updated, see Client features.
When the DNS server receives a query, it first checks to see if it can answer the query authoritatively based on resource record information contained in a locally configured zone on the server. If the queried name matches a corresponding resource record in local zone information, the server answers authoritatively, using this information to resolve the queried name.
If no zone information exists for the queried name, the server then checks to see if it can resolve the name using locally cached information from previous queries. If a match is found here, the server answers with this information. Again, if the preferred server can answer with a positive matched response from its cache to the requesting client, the query is completed.
If the queried name does not find a matched answer at its preferred server -- either from its cache or zone information -- the query process can continue, using recursion to fully resolve the name. This involves assistance from other DNS servers to help resolve the name. By default, the DNS Client service asks the server to use a process of recursion to fully resolve names on behalf of the client before returning an answer. In most cases, the DNS server is configured, by default, to support the recursion process as shown in the following figure.
In order for the DNS server to do recursion properly, it first needs some helpful contact information about other DNS servers in the DNS domain namespace. This information is provided in the form ofroot hints, a list of preliminary resource records that can be used by the DNS service to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree. Root servers are authoritative for the domain root and top-level domains in the DNS domain namespace tree. For more information, see Updating root hints.
By using root hints to find root servers, a DNS server is able to complete the use of recursion. In theory, this process enables any DNS server to locate the servers that are authoritative for any other DNS domain name used at any level in the namespace tree.
For example, consider the use of the recursion process to locate the name "host-b.example.microsoft.com." when the client queries a single DNS server. The process occurs when a DNS server and client are first started and have no locally cached information available to help resolve a name query. It assumes that the name queried by the client is for a domain name of which the server has no local knowledge, based on its configured zones.
First, the preferred server parses the full name and determines that it needs the location of the server that is authoritative for the top-level domain, "com". It then uses an iterative (that is, a nonrecursive) query to the "com" DNS server to obtain a referral to the "microsoft.com" server. Next, a referral answer comes from the "microsoft.com" server to the DNS server for "example.microsoft.com".
Finally, the "example.microsoft.com." server is contacted. Because this server contains the queried name as part of its configured zones, it responds authoritatively back to the original server that initiated recursion. When the original server receives the response indicating that an authoritative answer was obtained to the requested query, it forwards this answer back to the requesting client and the recursive query process is completed.
Although the recursive query process can be resource-intensive when performed as described above, it has some performance advantages for the DNS server. For example, during the recursion process, the DNS server performing the recursive lookup obtains information about the DNS domain namespace. This information is cached by the server and can be used again to help speed the answering of subsequent queries that use or match it. Over time, this cached information can grow to occupy a significant portion of server memory resources, although it is cleared whenever the DNS service is cycled on and off.
The previous discussion of DNS queries assumes that the process ends with a positive response returned to the client. However, queries can return other answers as well. These are the most common:
An authoritative answer is a positive answer returned to the client and delivered with the authority bit set in the DNS message to indicate the answer was obtained from a server with direct authority for the queried name.
A positive response can consist of the queried RR or a list of RRs (also known as an RRset) that fits the queried DNS domain name and record type specified in the query message.
A referral answer contains additional resource records not specified by name or type in the query. This type of answer is returned to the client if the recursion process is not supported. The records are meant to act as helpful reference answers that the client can use to continue the query using iteration.
A referral answer contains additional data such as resource records (RRs) that are other than the type queried. For example, if the queried host name was "www" and no A RRs for this name were found in this zone but a CNAME RR for "www" was found instead, the DNS server can include that information when responding to the client.
If the client is able to use iteration, it can make additional queries using the referral information in an attempt to fully resolve the name for itself.
A negative response from the server can indicate that one of two possible results was encountered while the server attempted to process and recursively resolve the query fully and authoritatively:
The resolver passes the results of the query, in the form of either a positive or negative response, back to the requesting program and caches the response.
Iteration is the type of name resolution used between DNS clients and servers when the following conditions are in effect:
An iterative request from a client tells the DNS server that the client expects the best answer the DNS server can provide immediately, without contacting other DNS servers.
When iteration is used, a DNS server answers a client based on its own specific knowledge about the namespace with regard to the names data being queried. For example, if a DNS server on your intranet receives a query from a local client for "www.microsoft.com", it might return an answer from its names cache. If the queried name is not currently stored in the names cache of the server, the server might respond by providing a referral -- that is, a list of NS and A resource records for other DNS servers that are closer to the name queried by the client.
When a referral is made, the DNS client assumes responsibility to continue making iterative queries to other configured DNS servers to resolve the name. For example, in the most involved case, the DNS client might expand its search as far as the root domain servers on the Internet in an effort to locate the DNS servers that are authoritative for the "com" domain. Once it contacts the Internet root servers, it can be given further iterative responses from these DNS servers that point to actual Internet DNS servers for the "microsoft.com" domain. When the client is provided records for these DNS servers, it can send another iterative query to the external Microsoft DNS servers on the Internet, which can respond with a definitive and authoritative answer.
When iteration is used, a DNS server can further assist in a name query resolution beyond giving its own best answer back to the client. For most iterative queries, a client uses its locally configured list of DNS servers to contact other name servers throughout the DNS namespace if its primary DNS server cannot resolve the query.
As DNS servers process client queries using recursion or iteration, they discover and acquire a significant store of information about the DNS namespace. This information is then cached by the server.
Caching provides a way to speed the performance of DNS resolution for subsequent queries of popular names, while substantially reducing DNS-related query traffic on the network.
As DNS servers make recursive queries on behalf of clients, they temporarily cache resource records (RRs). Cached RRs contain information obtained from DNS servers that are authoritative for DNS domain names learned while making iterative queries to search and fully answer a recursive query performed on behalf of a client. Later, when other clients place new queries that request RR information matching cached RRs, the DNS server can use the cached RR information to answer them.
When information is cached, a Time-To-Live (TTL) value applies to all cached RRs. As long as the TTL for a cached RR does not expire, a DNS server can continue to cache and use the RR again when answering queries by its clients that match these RRs. Caching TTL values used by RRs in most zone configurations are assigned the Minimum (default) TTL which is set used in the zone's start of authority (SOA) resource record. By default, the minimum TTL is 3,600 seconds (1 hour) but can be adjusted or, if needed, individual caching TTLs can be set at each RR.
Personeli akademik > Prof. Asoc. Dr. Endri Xhina > Lendet > 2015-2016 > Teknologjite Wireless ( Linux Admin) >