Everything you wanted to know about Root Name Servers

One of the foundations of the Internet is DNS.  We have talked about DNS alot.
http://www.mtin.net/blog/?s=DNS&submit=Search

There have been TBW Podcasts about DNS

So are you ready to get your geek on?
Let’s start with who operates the root name Servers. A quick visit to:
http://www.root-servers.org/

NetNod will explain the rest

Client subnet in DNS requests

Some Light Reading:
https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-00

Many Authoritative nameservers today return different replies based
   on the perceived topological location of the user.  These servers use
   the IP address of the incoming query to identify that location.
   Since most queries come from intermediate recursive resolvers, the
   source address is that of the recursive rather than of the query
   originator.

   Traditionally and probably still in the majority of instances,
   recursive resolvers are reasonably close in the topological sense to
   the stub resolvers or forwarders that are the source of queries.  For
   these resolvers, using their own IP address is sufficient for
   authority servers that tailor responses based upon location of the
   querier.

   Increasingly though a class of remote recursive servers has arisen
   that serves query sources without regard to topology.  The motivation
   for a query source to use a remote recursive server varies but is
   usually because of some enhanced experience, such as greater cache
   security or applying policies regarding where users may connect.
   (Although political censorship usually comes to mind here, the same
   actions may be used by a parent when setting controls on where a
   minor may connect.)  When using a remote recursive server, there can
   no longer be any assumption of close proximity between the originator
   and the recursive, leading to less than optimal replies from the
   authority servers.

   A similar situation exists within some ISPs where the recursive
   servers are topologically distant from some edges of the ISP network,
   resulting in less than optimal replies from the authority servers.

   This draft defines an EDNS0 option to convey network information that
   is relevant to the message but not otherwise included in the
   datagram.  This will provide the mechanism to carry sufficient
   network information about the originator for the authority server to
   tailor responses.  It also provides for the authority server to
   indicate the scope of network addresses that the tailored answer is
   intended.  This EDNS0 option is intended for those recursive and
   authority servers that would benefit from the extension and not for
   general purpose deployment.  It is completely optional and can safely
   be ignored by servers that choose not to implement it or enable it.

   This draft also includes guidelines on how to best cache those
   results and provides recommendations on when this protocol extension
   should be used.

For those of you running BIND here is some practical information
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#whats-edns0-all-about

DNS naming convention (Quick Tips)

For years we have done the following naming conventions for our DNS servers.

NS is reserved for authoritative name servers

DNS is reserved for caching servers.

For MTIN we have NS1.MTIN.NET and NS2.MTIN.NET which are authoritative for domains we host. DNS1.MTIN.NET and DNS2.MTIN.NET are for managed DNS customers.

Protecting your Mikrotik from DNS Amplification

There are several reasons and benefits to using your Mikrotik as a DNS caching server.  Queries to the client are just a tad faster, which makes the overall user experience seem snappier.  It also allows you to quickly change upstream DNS servers in the even of an outage, attack, etc.

There are two main avenues to think about when protecting Mikrotik from DNS.

The first is the incoming port 53 requests to the router.  You only want your customers to have access to query the Mikrotik.  In a simple scenario we have this:.

basic

ether1 is our upstream ISP connection.  Customers are other ports.  In this case if we want to block all port 53 requests from the outside world we specify the WAN interface to drop in the following code:

/ip firewall filter
add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop

This will still allow your Mikrotik to send out DNS queries because they are sourced from a non reserved port. We are simply blocking the Mikrotik from not answering port 53 requests on the external interface.

In a later post we will talk about what to do if you have multiple wan interfaces or multiple exit paths on your router (say running OSPF)

Post Show Specials

MTIN is offering some post WISPAPALOOZA specials

-Dude monitoring Instance. Bring up your own external Dude service for monitoring your network.
$20 a month with a free setup ($400 value)

-Hosted Spam Filtering for 1 domain $12 per month. 99.99% accurate

-Backup DNS Services $10 per month.

These specials are good until Halloween. After that they expire.

Most Popular Services

I was recently asked what some of our most popular services we offer to clients are.  The following are the top ones that come to mind

1.Converting bridged networks to routed
2.Remote Monitoring from our Data Centers. This allows a client to be notified in case they lose connectivity to the outside world.
3.Backend automation.  Implementing radius, monitoring links, and other things to give the ISP more information
4.Data Center services such as DNS hosting, circuit termination, and bandwidth.
5.Mikrotik configuration and support