Re: MWEB legal department - call for assistance

Hendrik Visage <[email protected]> Tue, 27 May 2014 15:24:54 +0200
Newsgroups gmane.org.operators.ioz
Message-ID <CADtGFv=oWUUikmDkWeQE81EVNVDXM3EEtrimPid=SA7xgdSYaQ@mail.gmail.com>
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