[CVALE] DNS Question

[Terry]

Hi Jason,

Thanks for your response.

You wrote:
 > I'm sure you'll have passwords and all that good stuff.  I think what
 > you're really trying to avoid is advertising your front door so folks
 > won't even be trying to guess passwords in the first place.

This is correct I don't want to make it any easier for the bad guys than necessary.  If they don't 
know the door exists they won't try to open it.  I can't eliminate the guys just trying every IP 
address.

Good point about a sniffer looking at plaintext DNS queries.  Although the content transfer will be 
using SSL (oops TLS, I can't keep up  :-) ) I can't get around the small exposure with this DNS step 
unless I have the users reference the more abstract IP address instead of the domain name.

Thanks for the tip about wildcarding the domain name in the robots.txt file.

I wasn't aware of DNSSEC at all.  Not that I keep up on this stuff.  Thanks for letting us all know 
about the unorthodox zone transfer method with the "weakness" in NSEC (versus NSEC3).

It sounds like DNSSEC is still a plaintext query except for the signature/hash code.  Is this 
correct, so that a sniffer can be used to monitor/display the DNS query and response content with 
DNSSEC traffic?

Terry


Jason Roysdon wrote:
> Terry,
> 
> Hey, as Kristian pointed out, what you're looking for is security
> through obscurity.  But any ISP's DNS server that you or your users have
> configured as their PC's resolver is going to have that info cached.
> Further, DNS queries are plaintext, so anyone can monitor those queries,
> etc.  Unlikely that anyone is going to be doing that, and I'm sure there
> is much more juicy stuff if someone was doing that.
> 
> I'm sure you'll have passwords and all that good stuff.  I think what
> you're really trying to avoid is advertising your front door so folks
> won't even be trying to guess passwords in the first place.  As Kristian
> said, so long as your ISP has its DNS server properly configured to now
> allow AXFR, you're all good.
> 
> I would make sure you put a robots.txt file to block any indexing of
> your website in case someone "leaks" your URLs.  You'll want to do a
> wildcard method like *.yourdomain.com so you won't be leaking the
> domains via your robots.txt file.
> 
> One minor point that doesn't apply to people immediately, but may
> eventually: DNSSEC.  DNSSEC is the ability for a DNS server to verify
> that the contents of a reply have not been modified by verifying a
> crypto signature.
> 
> DNSSEC is mandated for all US Federal Agencies (.GOV) by the end of '09.
>  .GOV is already DNSSEC signed as of January, '09.
> 
> Sounds good, right?  The one problem is that DNSSEC allows you to verify
> that a piece of information doesn't exist, aka an NSEC reply.  With
> NSEC, it does so by giving an error and giving you the next piece of
> information, for which you can verify the signature and know that it is
> true.
> 
> For instance, I could ask if 0.osdl.org exists, and it will error back
> that it doesn't and the next record alphabetical record is
> anything.osdl.org or whatever.  I could then ask for l.osdl.org and it
> would answer back with linux.osdl.org.  Then I'd ask for linux0.osdl.org
> and if it were next it would come back with linux-raid.osdl.org.  This
> is called enumeration and it basically lets you do a record by record
> transfer of an entire zone.  There are scripts that automate, and you
> can run them against large cc-TLDs or any zone that has NSEC enabled and
> can basically do a full zone transfer.  This is exactly what you're
> trying to avoid, Terry.
> 
> So, many Registrars and agencies (like the US Federal Government) balked
> at this problem with DNSSEC NSEC revealing what is in their zones.
> NSEC3 was created then to solve this and uses a hash based on the next
> record answer, and therefore doesn't reveal the contents of the next
> record, but accomplishes the same task of verifying that a given record
> doesn't exist.
> 
> So, long story short: if you want to hide what is in your DNS, and you
> need or want to enable DNSSEC, then do so with NSEC3, not NSEC.
> 
> Also note that BIND9.6 is required for NSEC3.  This is a problem for
> folks running RHEL5/CentOS5 as that's still running at BIND9.3.4-10.P1.
>  I've opened a bug with RedHat and we'll see what they say, as the
> Federal Government is requiring NSEC3 resolvers and they're not a small
> customer.  https://bugzilla.redhat.com/show_bug.cgi?id=504052
> 
> 
> Hope things go well with your venture, Terry.
> 
> Take care all,
> Jason Roysdon
> http://Roysdon.net
> 
> 
> Terry wrote:
>> Hi Kristian,
>>
>> Thanks for confirming my understanding of this.  It's a minor security point but I don't want to 
>> make it any easier than necessary for this server to be attacked, yet still provide convenience for 
>> it's users.
>>
>> Terry
>>
>>
>> Kristian Hoffmann wrote:
>>> Hi Terry!
>>>
>>> On Sat, 2009-05-02 at 19:26 -0700, Terry wrote:
>>> ...
>>>> My question is...
>>>> Is there any DNS query (or series of queries) that would reveal the list of hosts (or subdomains) on 
>>>> a domain if zone file transfers are restricted at the DNS server?
>>> To my knowledge, no.  Short of compromising an authoritative DNS server,
>>> there's no way to get a list of records in a given zone without the
>>> ability to do a zone transfer (AXFR).  The next best thing is a
>>> dictionary attack against the zone, but you're much more likely to be
>>> port scanned first.  Security through obscurity...
>>>
>>> Take care,
>>>
>>> -Kristian
>>>
>> _______________________________________________
>> cvale mailing list
>> cvale at lists.fire2wire.com
>> http://lists.fire2wire.com/mailman/listinfo.cgi/cvale
>>
> 
> 
> _______________________________________________
> cvale mailing list
> cvale at lists.fire2wire.com
> http://lists.fire2wire.com/mailman/listinfo.cgi/cvale
>