Bind-9.5.0-P2 testing

[Kevin Darcy]

Binmakhashen, Latif wrote:
>
> Good points Kevin!!!
>
> 1) This is weird, the command line with the -v flag is showing the 
> right version but the output from the command is referring to an 
> earlier version which is not installed at all?
>
> Internal DNS seems to refer to an older version that doesn’t exist in 
> the system? I see something that maybe causing that so I’ll 
> investigate this some more and will keep you guys updated.
>
> # ./dig -v
>
> DiG 9.5.0-P2
>
That's just showing you the version of the "dig" binary. Which may be 
completely different than the version of your "named" binary.
>
> # ./dig version.bind chaos txt
>
> ; <<>> DiG 9.5.0-P2 <<>> version.bind chaos txt
>
> ;; global options: printcmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1704
>
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
>
> ;version.bind. CH TXT
>
> ;; ANSWER SECTION:
>
> version.bind. 0 CH TXT "9.2.0"
>
> ;; Query time: 2 msec
>
> ;; SERVER: 172.16.1.48#53(172.16.1.48)
>
> ;; WHEN: Mon Aug 18 19:23:47 2008
>
> ;; MSG SIZE rcvd: 48
>
BIND 9.2.0 is unpatched and will have poor resilience against the 
Kaminsky attack. If it's a purely "internal" server, this may not be 
much of a concern for you. If you have joint-venture and/or "business 
partner"/vendor connections on your network that you don't fully 100% 
trust, however, you might want to consider patching your internal 
nameservers too. The distinction between "internal" and "external" is 
slowly degenerating over time.
>
> External DNS is using the right binaries but same result?
>
> # ./dig -v
>
> DiG 9.5.0-P2
>
> # ./dig version.bind chaos txt
>
> ; <<>> DiG 9.5.0-P2 <<>> version.bind chaos txt
>
> ;; global options: printcmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24343
>
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
>
> ;version.bind. CH TXT
>
> ;; ANSWER SECTION:
>
> version.bind. 0 CH TXT ""
>
> ;; AUTHORITY SECTION:
>
> version.bind. 0 CH NS version.bind.
>
> ;; Query time: 11 msec
>
> ;; SERVER: 10.0.0.3#53(10.0.0.3)
>
> ;; WHEN: Mon Aug 18 19:10:08 2008
>
> ;; MSG SIZE rcvd: 57
>
named.conf has been configured to obscure the version number.

Apparently whoever did that has never heard of DNS server fingerprinting.
>
> # ./dig +short porttest.dns-oarc.net TXT
>
> porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
>
> "12.109.107.10 is POOR: 26 queries in 2.1 seconds from 1 ports with 
> std dev 0"
>
> 2) Yes, you’re right we do have the query-source statement in the 
> named.conf and that is what I doubted when I saw the source port 
> randomness was POOR. What is your recommendations?
>
> query-source address * port 53;
>
The recommendation is to remove the query-source restriction, in 
co-operation with liberalizing your firewall rules, if necessary, to 
allow source ports other than 53 to communicate with outside DNS servers 
and receive responses from them.

If that isn't feasible in your timeframe, an alternate suggestion -- 
perhaps as a temporary measure -- is to forward to some other DNS 
resolver that is resilient against the Kaminsky attack. OpenDNS is 
frequently mentioned as a free service in this regard, but I can't 
recommend them.

- Kevin

> 3) I’ll check with the network admins. It’s mentioned in the security 
> article but the network guy I want to talk to wasn’t in today:
>
> http://www.kb.cert.org/vuls/id/800113
>
> Kind regards,
>
> Latif Binmakhashen
>
> Sr. Unix Admin.
>
> Omnicare Inc.
>
> Direct Line: (614) 652-3217
>
> latif.binmakhashen at omnicare.com
>
> -- NOTICE --
>
> This e-mail message is confidential, intended only for the named 
> recipient(s) above and may contain information that is privileged or 
> exempt from disclosure under applicable law. If you have received this 
> message in error, or are not the named recipient(s), please 
> immediately notify the sender and delete this e-mail message from your 
> computer.
>
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On 
> Behalf Of Kevin Darcy
> Sent: Monday, August 18, 2008 7:09 PM
> To: bind-users at isc.org
> Subject: Re: Bind-9.5.0-P2 testing
>
> Binmakhashen, Latif wrote:
>
> > That's a very interesting question because I'm pretty much on the same
>
> > boat.
>
> > I just upgraded to bind-9.5.0-P2 and was looking for a good tool that
>
> > will show me if this version really fixes the DNS cache poisoning issue.
>
> >
>
> > I found the following tool which I believe is pretty good but it
>
> > probably does more check than just the DNS cache poisoning...
>
> >
>
> > Go here and under Testing and Reporting Tools, run the DNS Vulnerability
>
> > Testing Tool => Test Now.
>
> >
>
> > http://www.infoblox.com/library/dns-security-center.cfm#2
>
> >
>
> > I'm getting POOR for the Source Port randomness and GREAT for the
>
> > transaction ID randomness.
>
> > Is that expected? Does the source port randomness has something to do
>
> > with the way named.conf is setup?
>
> >
>
> > Also, another test from the command line is showing a POOR result? Refer
>
> > to the following link for more info about the command line test:
>
> >
>
> > https://www.dns-oarc.net/oarc/services/porttest
>
> >
>
> > # dig @hpadm2 +short porttest.dns-oarc.net TXT
>
> > porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.n
>
> > et.
>
> > "12.109.107.60 is POOR: 26 queries in 2.1 seconds from 1 ports with std
>
> > dev 0"
>
> >
>
> >
>
> > Anybody has an idea?
>
> >
>
> >
>
> 1. You're not using the binary you think you're using (try "dig
>
> version.bind chaos txt")
>
> 2. You have a "query-source" statement in named.conf
>
> 3. Some intermediate device -- DNS forwarder (if configured), firewall,
>
> PNAT -- is "de-randomizing" your packets.
>
> - Kevin
>
> ------------------------------------------------------------------------
>
> *-- NOTICE -- The information transmitted is intended only for the 
> person or entity to which it is addressed and may contain confidential 
> and/or privileged material, the disclosure of which is governed by 
> applicable law. Any review, retransmission, dissemination or other use 
> of, or taking of any action in reliance upon, this information by 
> persons or entities other than the intended recipient is prohibited. 
> If you received this in error please contact the sender and destroy 
> the materials contained in this message. *
>