Linux

Domain name server (DNS)

Posted on

explain Authoritative Nameserver and Recursive Resolver

An authoritative Nameserver is a nameserver (DNS Server) that holds the actual DNS records (A, CNAME, PTR, etc) for a particular domain/ address. A recursive resolver would be a DNS server that queries an authoritative nameserver to resolve a domain/ address.

So, for example, If I have  a DNS server in my network that holds an A record for foobar.com, my DNS server would be authoritative for the foobar.com domain.

If clients needed to access foobar.com, they could query my DNS server and they would get an authoritative response.

However, if a client needed to access contoso.com, and they queried my DNS server, it would not have records to resolve that domain. In order for my DNS server to resolve contoso.com, it would need to use recursive lookups (via Forwarders or Root Hints). My DNS server would be set to send queries for domains for which it is not authoritative, to another DNS server. That DNS server would do the same, until the query reached a DNS server that was authoritative for contoso.com. That DNS server would return the proper records, which would be passed all the way back down to the client.

This is an oversimplification, as there are other things in play here, like caching records.

An authoritative nameserver is one that satisfies queries from its own data without needing to reference another source. Unless it is also a recursive nameserver (a practice which is generally deprecated) it will answer only with authoritative data from its own store (which can come from a zone master file, from a copy of that data transferred from a master server, from a database, from dynamic DNS, be built in, etc.) or with a referral (e.g. “I don’t know that answer, but you can talk to server so-and-so, who answers questions for this subdomain..), or with an NXDOMAIN or similar error.

A recursive nameserver is one that satisfies queries by asking other nameservers for the answer, traversing the tree from the root level of the DNS tree if necessary. If it does not know the answer it will attempt to find it for the querying client.

A resolver is (collectively) the set of functionality that a DNS-aware system uses to query DNS.

  • Most client systems have a stub resolver, which knows only in a very basic fashion how to query a DNS server and how to receive an answer, but which does not contain logic for following a delegation chain from the root.
  • A recursing resolver is a full-service resolver which can traverse the tree to find an answer to a query.
  • Recursive nameservers must contain the functionality of a recursing resolver in order to function, but other programs may contain recursing resolvers without performing the functions of a nameserver. An excellent example is the utility / DNS-troubleshooting program “dig” (distributed by ISC as a part of BIND) which contains a full recursing resolver.

DNS concepts which are sometimes confused with the distinction between authoritative and recursive:

There are several DNS concepts which people sometimes confuse with the split between authoritative and recursive data.

Delegation

This one confuses quite a few people, particularly because the name of the SOA (start of authority) resource record type contains the word “authority” which sounds as though it should be related to “authoritative.” However, you can serve authoritative data for a zone which is not delegated to you, and many people do. Examples include DNS-based content blocking and servers which provide authoritative answers for RFC 1918 zones [i.e. nobody has delegated you authority to answer PTR record queries for 168.192.in-addr.arpa (192.168.0.0/16) and similar zones but it’s not a bad idea for your server to answer such queries authoritatively rather than leak queries for those zones to the internet, where nobody is delegated to answer them. ISC BIND and other nameservers provide built-in zone data for these private address space zones to prevent the in-addr.arpa servers from being bombarded with queries that cannot be referred.]

It is not required that you be delegated authority for a zone in order for answers to be considered authoritative.

Master and Slave

Slave servers, even though they get their zone data from another source, are still authoritative servers, as they are satisfying queries with data from their own storage (of whatever type) rather than satisfying it by relaying the queries recursively to other nameservers.

Slave servers are authoritative servers (for the zones they serve.)

Understanding Zone Types

The DNS Server service provides for three types of zones:

  • Primary zone
  • Secondary zone
  • Stub zone

The following sections describe each of these zone types.

Primary zone

When a zone that this DNS server hosts is a primary zone, the DNS server is the primary source for information about this zone, and it stores the master copy of zone data in a local file or in AD DS. When the zone is stored in a file, by default the primary zone file is named zone_name.dns and it is located in the %windir%\System32\Dns folder on the server.

Secondary zone

When a zone that this DNS server hosts is a secondary zone, this DNS server is a secondary source for information about this zone. The zone at this server must be obtained from another remote DNS server computer that also hosts the zone. This DNS server must have network access to the remote DNS server that supplies this server with updated information about the zone. Because a secondary zone is merely a copy of a primary zone that is hosted on another server, it cannot be stored in AD DS.

Stub zone

When a zone that this DNS server hosts is a stub zone, this DNS server is a source only for information about the authoritative name servers for this zone. The zone at this server must be obtained from another DNS server that hosts the zone. This DNS server must have network access to the remote DNS server to copy the authoritative name server information about the zone.

You can use stub zones to:

  • Keep delegated zone information current. By updating a stub zone for one of its child zones regularly, the DNS server that hosts both the parent zone and the stub zone will maintain a current list of authoritative DNS servers for the child zone.
  • Improve name resolution. Stub zones enable a DNS server to perform recursion using the stub zone’s list of name servers, without having to query the Internet or an internal root server for the DNS namespace.
  • Simplify DNS administration. By using stub zones throughout your DNS infrastructure, you can distribute a list of the authoritative DNS servers for a zone without using secondary zones. However, stub zones do not serve the same purpose as secondary zones, and they are not an alternative for enhancing redundancy and load sharing.

There are two lists of DNS servers involved in the loading and maintenance of a stub zone:

  • The list of master servers from which the DNS server loads and updates a stub zone. A master server may be a primary or secondary DNS server for the zone. In both cases, it will have a complete list of the DNS servers for the zone.
  • The list of the authoritative DNS servers for a zone. This list is contained in the stub zone using name server (NS) resource records.

When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the master servers, which can be in different locations, for the necessary resource records of the authoritative servers for the zone widgets.tailspintoys.com. The list of master servers may contain a single server or multiple servers, and it can be changed anytime.

Posted By-: Vissicomp Technology Pvt. Ltd.

Website -: http://www.vissicomp.com

Advertisements

Linux Administration

Posted on Updated on

Important commands for NFS

  showmount -e : Shows the available shares on your local machine

  showmount -e <server-ip or hostname>: Lists the available shares at the remote server

  showmount -d : Lists all the sub directories

  exportfs -v : Displays a list of shares files and options on a server

  exportfs -a : Exports all shares listed in /etc/exports, or given name

  exportfs -u : Unexports all shares listed in /etc/exports, or given name

  exportfs -r : Refresh the server’s list after modifying /etc/exports

NFS server configuration commands:

#rpm –qa | grep nfs

#ifconfig

#pwd

[root@nfsserver ~]# mkdir /nfsshare

#cd nfsshare

#touch f1 f2 f3

#vi /etc/exports

            Edit the file with line:

                        /root/nfsshare client’s ip address(rw,sync,no_root_squash)

   Save file.

NFS Options

Some other options we can use in “/etc/exports” file for file sharing is as follows.

  1. ro: With the help of this option we can provide read only access to the shared files i.e client will only be able to read.
  2. rw: This option allows the client server to both read and write access within the shared directory.
  3. sync: Sync confirms requests to the shared directory only once the changes have been committed.
  4. no_subtree_check: This option prevents the subtree checking. When a shared directory is the subdirectory of a larger file system, nfs performs scans of every directory above it, in order to verify its permissions and details. Disabling the subtree check may increase the reliability of NFS, but reduce security.
  5. no_root_squash: This phrase allows root to connect to the designated directory.

#service nfs restart

Setting Up the NFS Client

After configuring the NFS server, we need to mount that shared directory or partition in the client server.

Mount Shared Directories on NFS Client

Now at the NFS client end, we need to mount that directory in our server to access it locally. To do so, first we need to find out that shares available on the remote server or NFS Server

root@nfsclient ~]# showmount -e 192.168.0.100

Export list for 192.168.0.100:/nfsshare 192.168.0.101

Note: here 192.168.0.100 is server’s ip address while 192.168.0.101 is client’s ip address.

Above command shows that a directory named “nfsshare” is available at “192.168.0.100” to share with your server.

Mount Shared NFS Directory

To mount that shared NFS directory we can use following mount command.

root@nfsclient ~]# mount -t nfs 192.168.0.100:/nfsshare           /mnt/nfsshare

The above command will mount that shared directory in “/mnt/nfsshare” on the client server. You can verify it following command.      

[root@nfsclient ~]# mount | grep nfs sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)nfsd on /proc/fs/nfsd type nfsd (rw)192.168.0.100:/nfsshare on /mnt type nfs (rw,addr=192.168.0.100)

 

The above mount command mounted the nfs shared directory on to nfs client temporarily, to mount an NFS directory permanently on your system across the reboots, we need to make an entry in “/etc/fstab“.

Testing NFS mount:

#cd /mnt/nfsshare

#ls

f1 f2 f3

Removing the NFS Mount

If you want to unmount that shared directory from your server after you are done with the file sharing, you can simply unmount that particular directory with “umount” command. See this example below.

root@nfsclient ~]# umount /mnt/nfsshare

Posted By-: Vissicomp Technology Pvt. Ltd.

Website -: http://www.vissicomp.com

 

Linux

Posted on Updated on

1.    What is Linux?

Linux is, in simplest terms, an operating system. It is the software on a computer that enables applications and the computer operator to access the devices on the computer to perform desired functions. The operating system (OS) relays instructions from an application to, for instance, the computer’s processor. The processor performs the instructed task, then sends the results back to the application via the operating system.

But something sets Linux apart from these operating systems. The Linux operating system represented a $25 billion ecosystem in 2008. Since its inception in 1991, Linux has grown to become a force in computing, powering everything from the New York Stock Exchange to mobile phones to supercomputers to consumer devices.

As an open operating system, Linux is developed collaboratively, meaning no one company is solely responsible for its development or ongoing support. Companies participating in the Linux economy share research and development costs with their partners and competitors. This spreading of development burden amongst individuals and companies has resulted in a large and efficient ecosystem and unheralded software innovation.

Over 1,000 developers, from at least 100 different companies, contribute to every kernel release. In the past two years alone, over 3,200 developers from 200 companies have contributed to the kernel–which is just one small piece of a Linux distribution.

This article will explore the various components of the Linux operating system, how they are created and work together, the communities of Linux, and Linux’s incredible impact on the IT ecosystem.

  1. Where is Linux?

One of the most noted properties of Linux is where it can be used. Windows and OS X are predominantly found on personal computing devices such as desktop and laptop computers. Other operating systems, such as Symbian, are found on small devices such as phones and PDAs, while mainframes and supercomputers found in major academic and corporate labs use specialized operating systems such as AS/400 and the Cray OS.

Linux, which began its existence as a server OS and Has become useful as a desktop OS, can also be used on all of these devices. ‚ÄúFrom wristwatches to supercomputers,‚Äù is the popular description of Linux’ capabilities.

An abbreviated list of some of the popular electronic devices Linux is used on today includes:

These are just the most recent examples of Linux-based devices available to consumers worldwide. This actual number of items that use Linux numbers in the thousands. The Linux Foundation is building a centralized database that will list all currently offered Linux-based products, as well as archive those devices that pioneered Linux-based electronics.

Linux_1
Linux_1

Posted by Vissicomp Technology Pvt Ltd

ww.vissicomp.com