Re: MWEB legal department - call for assistance

Don't get me wrong, I am not advocating not having separate authoritative
and resolvers, 

Just an interesting scenario. 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Hendrik Visage
Sent: 27 May 2014 03:25 PM
To: IOZ
Subject: Re: [IOZ] MWEB legal department - call for assistance

On Tue, May 27, 2014 at 9:06 AM, Saul <[email protected]> wrote:
> HI Mark,
>
> Interesting point you make, something that I have been pondering of
late:
>
>>The two types of Nameservers should be kept completely separate. A 
>>Recursive server must find an answer to a query by chasing the >answer 
>>down from the root. (And of course cache it for the designated time..)
>
> Yes I agree 100% one has recursive and authoritative servers.
>
> Lets work through the following scenario:
>
> Just say I have both. My authoritative servers are responsible for 
> 1000s of domains. Why would I want my tens of thousands of eyeballs, 
> going to the root servers, inducing extra latency when if they could 
> just look at the authoritative server, the responses would be much
better.
>
> OK, one reason is that it would break DNS sec, but for smaller ISPs, 
> it is very important to keep the DNS for your clients up. If your 
> upstream were to loose connectivity the return to root, causes even 
> your directly connected clients to loose connectivity (DNS) to you. 
> Yes, I might have other routes to get to the root servers, but other 
> levels of the DNS tree, so might know where to look for .za, but can't 
> get to them to look for co.za
>
> Any thoughts?

Yes loads ;)

Not to re-iterated what the others like Mark, Calvin etc. said that is all
relevant, let me add the following from a "small(all?) ISP"
implementation point of view:

1) Authoritative servers
 a) "primary" behind firewall(s) of sorts preferably not  queriable from
the outside
 b) Secondaries (those that you advertise in you NS records) should be
geographically distributed. ie. one at your premises/major PoP, and then
the rest with your other PoPs and preferably at least one other provider
on a different AS number from you (or your upstream(s)) in another
geographical place
 c) These servers allow access from 0.0.0.0/0,
 d) should DROP any non-authoritative request and preferably you should
have some rate limiter per source IP  (read DNS dDOS attacking somebody
else and your bandwidth being consumed if not... what is that attack's
name again, was hitting local ISPs last year this time)

2) Recursive resolvers
 i) you'll have multiple resolvers, and preferably multiple per PoP, thus
your clients connect to the closest one
 ii) If you don't have local redundancy then then a failure of a resolver
will impact your clients
 iii) they answer DNS for your clients' IP address range(s) *only* (Refer
to point (d) under Authoritative servers)
 iv) they'll drop any other requests from 0.0.0.0/0 that have not been
handled by (iii)
 v) using unbound, there is a method to periodically dump the cached data,
and then if you restart your VM/server you can then reload that cache dump
so that you can speedup the initial seeding requests for your clients
(makes me think I could also use that to have two instance seed each other
where the primary resolver will seed the secondary for in case the primary
dies/rebooted get dDOSed/etc.)


*sigh*
 I miss the days of BIND 4, sendmail and INND when we *trusted* the other
DARPA/UniNET users and not like today where we distrust the whole Internet
;(

_______________________________________________
IOZ mailing list
[email protected]
http://lists.internet.org.za/mailman/listinfo/ioz

_______________________________________________
IOZ mailing list
[email protected]
http://lists.internet.org.za/mailman/listinfo/ioz