[vox-tech] inject false information into dns

[Rick Moen]

Quoting Tony Cratz (cratz at hematite.com):

> > This prevents hackers from injecting false information (aka DNS cache
> > 'poisoning'), in an attempt to re-direct people trying to access a real
> > website to a fake, phishing or criminal site.
> 
> 	I will attempt to answer you question by giving a very high
> 	level overview.
> 
> 	I do ask others (Rick, Alex and any other person who knows DNS)
> 	to keep me correct if (when) I say something wrong, if if they
> 	feel I left something out which needs to be covered.

Thanks for your thoughtful run-through.  It makes me feel like a bad
penny breezing in and doing drive-by comments:  Apologies for not having
the time to write a more-careful and considered rejoinder.

> 	Paul Vixie (and others) decided we needed a better method
> 	and developed Bind which used the Domain Name System instead
> 	of bang-paths.

FWIW (and not any kind of criticism, just historical trivia), there was
an overlapping step where first ARPANET and then the InterNIC at SRI
International maintained a central HOSTS.TXT file (per RFC 953) that
could be fetched from a standard location via ftp.

> 	Of late, Ubuntu has gone one more step, they have set-up what is
> 	called a 'caching name server' when you use DHCP.

Have they?  Good.  OTOH, it's always been trivial to set up a local
nameserver for better performance, reliability, and security.  The term
'caching name server' is one I would avoid using in favour of clearer
alternatives that are more specific and meaningful.  (Again, I mean no
criticism of your fine explanation, but wish to bring additional clarity
to the subject.)

1.  _All_ DNS servers of various and sundry sorts do caching -- so
saying that a nameserver is a 'caching name server' really doesn't tell
you much.

2.  Far more meaningful is whether the nameserver does authoritative
service or not.  (By 'authoritative' service, I mean serves up
information of its own, as opposed to querying, caching, and providing
DNS data sourced from elsewhere.)

The other type of DNS service -- serving up and caching data queried
from elsewhere -- is somewhat loosely called recursive service.
Complicating the nomenclature somewhat is the fact that a DNS server's
query to another DNS server can either have the 'recursion desired' (RD)
bit or not.  The query thus characterised (RD bit set vs RD bit unset)
is called either a recursive query or an iterative query.  Those queries
are treated differently by the receiving nameserver.

Last, there is the issue of forwarding, to which you alluded.  A few DNS 
server packages (dproxy, Dnsmasq) have essentially no local
DNS-resolution intelligence of their own and are capable _only_ of
forwarding to a more-capable nameserver any queries local processes +
hosts submit to them.  (As you said, BIND9 can be configured to forward
elsewhere queries whose answers it doesn't have in cache.  It differs
from dproxy and Dnsmasq in having a considerable amount of local
DNS-resolving intelligence that can be used if you wish to do so.)

As these nuances are a bit complex and a bit counter-intuitive, I long
ago wrote a (metaphorical) 'networking fairy tale' about the mythical
Village of Lan to illustrate them:

http://linuxmafia.com/~rick/lan.html

Also, I have classified and summarised all DNS software for Linux
according to what sort of service it does:

http://linuxmafia.com/faq/Network_Other/dns-servers.html


> 	If you run your own name service (BIND-9), depending on how you
> 	set it up you can still use your ISP as a 'forwarder'. This
> 	means, instead of doing a recursive search up to the TLD and
> 	then down to the DNS server for the domain we just ask the ISP
> 	if they have the domain in their cache (and most of the major
> 	sites will be already in the cache). By using 'forwarders' you
> 	can save a lot of time by not having to do the full search.

I beg your indulgence for my polite difference of opinion.  (I have the
discussion often.)


As background:  Specifying forwarders tells BIND9 to not use its
independent ability to resolve DNS questions whose answers aren't
already in the local cache (aside for records for which it's
authoritative), but rather to offload all uncached queries to one or
more remote nameserver (with the RD bit set) and have those do the work.  
The belief that this 'saves a lot of time' rests on the undeniable fact
that ISP nameservers tend to run with a bountiful cache set.  

Thus, initially the ISP nameserver has an advantage on account of the
loaded cache.  However, over a quite short period of time, your local
cache fills quite beautifully with or without a forwarders line, so any
initial advantage evaporates almost entirely within minutes.

But then the longer-term consideration becomes of interest:  ISP
nameservers (even those of good and praiseworthy ISPs) are a very
serious security and performance / reliability weak spot.  The security
problem arises even from diligent providers because recursive servers
inherently run the risk of cache poisoning, easier DoSing, and other
security failures unique to that variety of service, and the more public
a recursive server is, the bigger the risk of problems.

Then, too, don't forget that the ISP namserver is typically at the far
side of a slow, latency-laden last-mile link (e.g., aDSL, ISDN, MiFi, or
even dial-up) -- not counting the fortunate few with their own T1 or T3
uplinks.  So, compared to your local LAN, your uplink is really slow for
anything including forwarded DNS queries and their responses.  Given
that you're going to pay that performance penalty for any type of
inbound or outbound traffic, you might as well process the whole query 
from a local recursive-capable nameserver on your side of the link.

I mean, yes, granted that resolving 'enzo.linuxmafia.com' from a local 
full-service nameserver host requires that your host find NS hosts for
com., then query one of those to get NS hosts for linuxmafia.com., and
then finally query one of those to get the ultimate answer -- but
practically all of that data then gets cached and reused with long TTL
values, and some of it you are pretty much guaranteed to have already in
cache (like com.'s NS data).


> 	The default method of setting up a DNS server (BIND-9) is to
> 	not use forward and do your own searches.

And that is what I strongly recommend -- with access to your recursive
service locked down tightly using ACLs.

Also, please see my dns-servers.html for things to consider instead of
BIND9.  Please.  Unbound and PowerDNS-Recursor are far better for the
recursive variety.  NSD and PowerDNS Authoritative Server are far better
for authoritative service.  And have been for quite a long time, now.


> 	Cache Poisoning - man-in-the-middle
> 
> 	BIND-9 like all programs has bugs in it. Because of how
> 	serious the bugs can be, BIND normally has a very quick turn
> 	around time to fix problem. But that does means all of the bugs
> 	have been found.

It's a big topic and I'm not prepared to do it justice at the moment.
But I'll note (once again) that in forwarding all your recursive queries
to an ISP nameserver you are radically increasing your security
exposure for a number of reasons including those servers having a huge
attack surface and fairly open access.

The Kaminsky bug description is helpful:
http://www.kb.cert.org/vuls/id/800113
(Note that a lot of people using NAT unknowingly screw up port
randomisation because their NAT gateways un-do it.)


> 	Reason for DNSSEC
> 
> 	To try to prevent the man-in-the-middle issue, we now want to
> 	insure that the machine we are talking to is the one and only
> 	machine we will trust (NOTE: all security is based on TRUST!!!)
> 	By using DNSSEC, we have a handshake which happens which goes
> 	like this:

To the extent it works and is (eventually, in the end of days)
pervasive, it could theoretically permit a nameserver to valigate what
is sending it data for records in domain $FOO.  There are various holes
in the rollout and the implementation, a serious performance hit, some
issues with DNS database size/complexity, and other teething problems.

Long story short, I wouldn't count on it as any kind of primary
defence in 2013.  (Other people who've drunk the Kool-Aid will argue.)

What's the alternative?  My own preference is:  Don't trust the damned
DNS for authenticating things.  (And no, I don't trust SSL Certificate
Authorities very much, either.)

And that, I'm sure, could be another long discussion.