NAME

Net::DNS::Nameserver - DNS server class

SYNOPSIS

use Net::DNS::Nameserver;

DESCRIPTION

Instances of the Net::DNS::Nameserver class represent DNS server objects. See /EXAMPLE for an example.

METHODS

new

 my $ns = Net::DNS::Nameserver->new(
	LocalAddr	 => "10.1.2.3",
	LocalPort	 => "5353",
	ReplyHandler => \&reply_handler,
	Verbose		 => 1
 );



 my $ns = Net::DNS::Nameserver->new(
	LocalAddr	 => ['::1' , '127.0.0.1' ],
	LocalPort	 => "5353",
	ReplyHandler => \&reply_handler,
	Verbose		 => 1
 );

Creates a nameserver object. Attributes are:

  LocalAddr		IP address on which to listen.	Defaults to INADDR_ANY.
  LocalPort		Port on which to listen.  	Defaults to 53.
  ReplyHandler		Reference to reply-handling 
			subroutine			Required.
  NotifyHandler         Reference to reply-handling
                        subroutine for queries with
                        opdcode NS_NOTIFY (RFC1996)
  Verbose		Print info about received 
			queries.			Defaults to 0 (off).

The LocalAddr attribute may alternatively be specified as a list of IP addresses to listen to.

If IO::Socket::INET6 and Socket6 are available on the system you can also list IPv6 addresses and the default is '0' (listen on all interfaces on IPv6 and IPv4);

The ReplyHandler subroutine is passed the query name, query class, query type and optionally an argument containing the peerhost the incoming query. It must return the response code and references to the answer, authority, and additional sections of the response. Common response codes are:

  NOERROR	No error
  FORMERR	Format error
  SERVFAIL	Server failure
  NXDOMAIN	Non-existent domain (name doesn't exist)
  NOTIMP	Not implemented
  REFUSED	Query refused

For advanced usage it may also contain a headermaks containing an hashref with the settings for the aa, ra, and ad header bits. The argument is of the form { ad => 1, aa => 0, ra => 1 }.

See RFC 1035 and the IANA dns-parameters file for more information:

  ftp://ftp.rfc-editor.org/in-notes/rfc1035.txt
  http://www.isi.edu/in-notes/iana/assignments/dns-parameters

The nameserver will listen for both UDP and TCP connections. On Unix-like systems, the program will probably have to run as root to listen on the default port, 53. A non-privileged user should be able to listen on ports 1024 and higher.

Returns a Net::DNS::Nameserver object, or undef if the object couldn't be created.

See /EXAMPLE for an example.

main_loop

	$ns->main_loop;

Start accepting queries. Calling main_loop never returns.

get_open_tcp

In scalar context returns the number of TCP connections for which state is maintained. In array context it returns IO::Socket objects, these could be useful for troubleshooting but be careful using them.

EXAMPLE

The following example will listen on port 5353 and respond to all queries for A records with the IP address 10.1.2.3. All other queries will be answered with NXDOMAIN. Authority and additional sections are left empty. The $peerhost variable catches the IP address of the peer host, so that additional filtering on its basis may be applied.

 #!/usr/bin/perl 
 
 use Net::DNS::Nameserver;
 use strict;
 use warnings;
 
 sub reply_handler {
	 my ($qname, $qclass, $qtype, $peerhost,$query) = @_;
	 my ($rcode, @ans, @auth, @add);

	 print "Received query from $peerhost\n";
	 $query->print;

	 
	 if ($qtype eq "A" && $qname eq "foo.example.com" ) {
		 my ($ttl, $rdata) = (3600, "10.1.2.3");
		 push @ans, Net::DNS::RR->new("$qname $ttl $qclass $qtype $rdata");
		 $rcode = "NOERROR";
	 }elsif( $qname eq "foo.example.com" ) {
		 $rcode = "NOERROR";

	 }else{
  	          $rcode = "NXDOMAIN";
	 }
	 

	 # mark the answer as authoritive (by setting the 'aa' flag
	 return ($rcode, \@ans, \@auth, \@add, { aa => 1 });
 }
 
 my $ns = Net::DNS::Nameserver->new(
     LocalPort    => 5353,
     ReplyHandler => \&reply_handler,
     Verbose      => 1,
 ) || die "couldn't create nameserver object\n";

 $ns->main_loop;

BUGS

Limitations in perl 5.8.6 makes it impossible to guarantee that replies to UDP queries from Net::DNS::Nameserver are sent from the IP-address they were received on. This is a problem for machines with multiple IP-addresses and causes violation of RFC2181 section 4. Thus a UDP socket created listening to INADDR_ANY (all available IP-addresses) will reply not necessarily with the source address being the one to which the request was sent, but rather with the address that the operating system choses. This is also often called "the closest address". This should really only be a problem on a server which has more than one IP-address (besides localhost - any experience with IPv6 complications here, would be nice). If this is a problem for you, a work-around would be to not listen to INADDR_ANY but to specify each address that you want this module to listen on. A seperate set of sockets will then be created for each IP-address.