Proposal to Add a DNS Cache Test to the Independent Component Schema

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal to Add a DNS Cache Test to the Independent Component Schema

Danny Haynes
Administrator

We would like to propose a new test for the OVAL Language that, given a domain name,

would collect all the IP addresses stored in the DNS cache on the local system.  This test

would apply to all platforms and would be placed in the independent component schema.

 

The dnscache_object will consist of a single domain_name entity that will be used to

guide the collection of the domain names stored in the DNS cache.  The dnscache_object

would be able to collect a single domain name, a subset of the domain names, or all of the

domain names present in the DNS cache.  The dnscache_state will contain a domain_name

entity that can be used to check the value of a domain_name and an ip_address entity that

can be used to the check the value of the IP address(es) associated with the domain name.

The dnscache_item will contain a domain_name entity that will represent a domain name

stored in the DNS cache and it will have zero or more ip_address entities that will each

represent an IP address associated with that domain name.

 

The following provides links to additional information that would be useful if this test

was to be implemented.

 

Windows:

To view the DNS cache from the command line: ipconfig /displaydns | more

http://technet.microsoft.com/en-us/library/cc758108(WS.10).aspx

           

Access the DNS cache with a function call: DnsQuery

http://msdn.microsoft.com/en-us/library/ms682016(VS.85).aspx

 

Linux/Solaris:

            To view the DNS cache from the command line: getent hosts <domain_name>

http://linux.die.net/man/1/getent

http://www.softpanorama.org/Net/Netutils/solaris_getent.shtml

           

Access the DNS cache with a function call: gethostbyname

http://linux.die.net/man/3/gethostbyname

http://ibgwww.colorado.edu/~lessem/psyc5112/usail/man/solaris/gethostbyname.3.html

 

Mac OS:

            To view the DNS cache from the command line: dscacheutil -cachedump –entries host

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dscacheutil.1.html

 

            Access the DNS cache with a function call: gethostbyname

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/gethostbyname.3.html

 

Also, I have attached a copy of the proposed changes to the independent schema for your review.

Would the addition of this test to the OVAL Language be beneficial to the community?  Is

there anything missing?   Please let me know if there any questions, comments, or concerns about

this proposal.

 

Thanks,


Danny

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

dnscache_item.xml (3K) Download Attachment
dnscache_test.xml (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Add a DNS Cache Test to the Independent Component Schema

Thomas Jones
Dan,

What is the intention of this proposal? What are the advantages? It seems that with this proposal that OVAL is expanding into a network-centric structure. Or at least considering such. 

Thanks. Thomas 

Sent from my iPhone

On Jan 28, 2010, at 12:22 PM, "Haynes, Dan" <[hidden email]> wrote:

We would like to propose a new test for the OVAL Language that, given a domain name,

would collect all the IP addresses stored in the DNS cache on the local system.  This test

would apply to all platforms and would be placed in the independent component schema.

 

The dnscache_object will consist of a single domain_name entity that will be used to

guide the collection of the domain names stored in the DNS cache.  The dnscache_object

would be able to collect a single domain name, a subset of the domain names, or all of the

domain names present in the DNS cache.  The dnscache_state will contain a domain_name

entity that can be used to check the value of a domain_name and an ip_address entity that

can be used to the check the value of the IP address(es) associated with the domain name.

The dnscache_item will contain a domain_name entity that will represent a domain name

stored in the DNS cache and it will have zero or more ip_address entities that will each

represent an IP address associated with that domain name.

 

The following provides links to additional information that would be useful if this test

was to be implemented.

 

Windows:

To view the DNS cache from the command line: ipconfig /displaydns | more

http://technet.microsoft.com/en-us/library/cc758108(WS.10).aspx

           

Access the DNS cache with a function call: DnsQuery

http://msdn.microsoft.com/en-us/library/ms682016(VS.85).aspx

 

Linux/Solaris:

            To view the DNS cache from the command line: getent hosts <domain_name>

http://linux.die.net/man/1/getent

http://www.softpanorama.org/Net/Netutils/solaris_getent.shtml

           

Access the DNS cache with a function call: gethostbyname

http://linux.die.net/man/3/gethostbyname

http://ibgwww.colorado.edu/~lessem/psyc5112/usail/man/solaris/gethostbyname.3.html

 

Mac OS:

            To view the DNS cache from the command line: dscacheutil -cachedump –entries host

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dscacheutil.1.html

 

            Access the DNS cache with a function call: gethostbyname

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/gethostbyname.3.html

 

Also, I have attached a copy of the proposed changes to the independent schema for your review.

Would the addition of this test to the OVAL Language be beneficial to the community?  Is

there anything missing?   Please let me know if there any questions, comments, or concerns about

this proposal.

 

Thanks,


Danny

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
<dnscache_item.xml>
<dnscache_test.xml>
To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Add a DNS Cache Test to the Independent Component Schema

Jon Baker
Administrator

We had a similar comment from a colleague here too and I realize that this could easily lead one down that path of wondering what else we might want to know about the network. This was not the purpose of this test proposal. The idea behind this test was simply to allow the dns cache on a local host to be examined, not to examine all sort of dns information and network properties that might be relevant.

 

This test will allow OVAL to examine all the dns entries that a give host has been talking to. In many cases the simple fact that a particular dns names appears in a host’s dns cache is an indicator that the system has been compromised in some way or that some incident has occurred. With this test I could examine all entries or look for one particular entry in the dns cache.

 

Does that help clarify that intent of the test?

 

Jon

 

============================================

Jonathan O. Baker

G022 - IA Industry Collaboration

The MITRE Corporation

Email: [hidden email]

 

From: Thomas R. Jones [mailto:[hidden email]]
Sent: Thursday, January 28, 2010 3:35 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] Proposal to Add a DNS Cache Test to the Independent Component Schema

 

Dan,

 

What is the intention of this proposal? What are the advantages? It seems that with this proposal that OVAL is expanding into a network-centric structure. Or at least considering such. 

 

Thanks. Thomas 

Sent from my iPhone


On Jan 28, 2010, at 12:22 PM, "Haynes, Dan" <[hidden email]> wrote:

We would like to propose a new test for the OVAL Language that, given a domain name,

would collect all the IP addresses stored in the DNS cache on the local system.  This test

would apply to all platforms and would be placed in the independent component schema.

 

The dnscache_object will consist of a single domain_name entity that will be used to

guide the collection of the domain names stored in the DNS cache.  The dnscache_object

would be able to collect a single domain name, a subset of the domain names, or all of the

domain names present in the DNS cache.  The dnscache_state will contain a domain_name

entity that can be used to check the value of a domain_name and an ip_address entity that

can be used to the check the value of the IP address(es) associated with the domain name.

The dnscache_item will contain a domain_name entity that will represent a domain name

stored in the DNS cache and it will have zero or more ip_address entities that will each

represent an IP address associated with that domain name.

 

The following provides links to additional information that would be useful if this test

was to be implemented.

 

Windows:

To view the DNS cache from the command line: ipconfig /displaydns | more

http://technet.microsoft.com/en-us/library/cc758108(WS.10).aspx

           

Access the DNS cache with a function call: DnsQuery

http://msdn.microsoft.com/en-us/library/ms682016(VS.85).aspx

 

Linux/Solaris:

            To view the DNS cache from the command line: getent hosts <domain_name>

http://linux.die.net/man/1/getent

http://www.softpanorama.org/Net/Netutils/solaris_getent.shtml

           

Access the DNS cache with a function call: gethostbyname

http://linux.die.net/man/3/gethostbyname

http://ibgwww.colorado.edu/~lessem/psyc5112/usail/man/solaris/gethostbyname.3.html

 

Mac OS:

            To view the DNS cache from the command line: dscacheutil -cachedump –entries host

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dscacheutil.1.html

 

            Access the DNS cache with a function call: gethostbyname

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/gethostbyname.3.html

 

Also, I have attached a copy of the proposed changes to the independent schema for your review.

Would the addition of this test to the OVAL Language be beneficial to the community?  Is

there anything missing?   Please let me know if there any questions, comments, or concerns about

this proposal.

 

Thanks,


Danny

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

<dnscache_item.xml>

<dnscache_test.xml>

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Add a DNS Cache Test to the Independent Component Schema

Matthew N. Wojcik
In reply to this post by Thomas Jones
Wow, I haven't gotten involved in an OVAL discussion in a long time.
And my hands-on experience with DNS is out of date enough that I'm
probably on thin ice in places here.  That said...

Comments inline.

On Jan 28, 2010, at 12:22 PM, "Haynes, Dan" <[hidden email]> wrote:

> We would like to propose a new test for the OVAL Language that,
> given a domain name, would collect all the IP addresses stored in
> the DNS cache on the local system.  This test would apply to all
> platforms and would be placed in the independent component schema.

I'm a bit worried that the functioning of DNS cacheing isn't universal
enough to really work in the independent schema.  It may be more
appropriate to create platform-specific tests.  After all, we have
separate Windows and Unix tests for process info and file info,
because even though there are shared concepts, the details are
different enough to merit separate tests.

For one thing, the ability may not always exist to specifically query
a DNS cache local to the particular end system.  On some platforms,
with a simple operation you may only be able to find out what the
resolving routines return for a given record.  Determining the
provenance of that information may be a very complicated multi-step
process, perhaps more complicated than is really ideal for a simple
OVAL test.  More on that in the system-specific sections below.

> The dnscache_object will consist of a single domain_name entity that
> will be used to guide the collection of the domain names stored in
> the DNS cache.  The dnscache_object would be able to collect a
> single domain name, a subset of the domain names, or all of the
> domain names present in the DNS cache.  The dnscache_state will
> contain a domain_name entity that can be used to check the value of
> a domain_name and an ip_address entity that can be used to the check
> the value of the IP address(es) associated with the domain name.
> The dnscache_item will contain a domain_name entity that will
> represent a domain name stored in the DNS cache and it will have
> zero or more ip_address entities that will each represent an IP
> address associated with that domain name.

My other reservations notwithstanding, I can imagine a number of
scenarios where it might be important to know what DNS information a
system is seeing.  And I saw Jon's message about not intending a
general-purpose DNS resolver test.  I think once you've got the
ability to look at A records, though, all the other DNS record types
are going to be wanted very quickly.  Why not just build them in now?

> The following provides links to additional information that would be
> useful if this test was to be implemented.
>
> Windows:
>
> To view the DNS cache from the command line: ipconfig /displaydns |
> more
> http://technet.microsoft.com/en-us/library/cc758108(WS.10).aspx
>
> Access the DNS cache with a function call: DnsQuery
> http://msdn.microsoft.com/en-us/library/ms682016(VS.85).aspx

I don't really know anything about DNS resolution and cacheing on
Windows, so I probably shouldn't comment here.  The test as propsed
may be fine for Windows.  Looking briefly at the documentation for
DnsQuery, it looks like DNS_QUERY_NO_WIRE_QUERY should be set as an
option, at least post-Windows 2000.  See

http://msdn.microsoft.com/en-us/library/cc982162(VS.85).aspx

> Linux/Solaris:
>
> To view the DNS cache from the command line: getent hosts
> <domain_name>
> http://linux.die.net/man/1/getent
> http://www.softpanorama.org/Net/Netutils/solaris_getent.shtml
>
> Access the DNS cache with a function call: gethostbyname
> http://linux.die.net/man/3/gethostbyname
> http://ibgwww.colorado.edu/~lessem/psyc5112/usail/man/solaris/gethostby
> name.3.html

I think these aren't going to give you what you want, as I understand
it.  On a Solaris 10 box I have access to, where the hosts entry in
/etc/nsswitch.conf is set to "files dns", "getent hosts" returns the
contents of the hosts file.  "getent hosts <domain_name>" invokes
gethostbyname(), which is the DNS resolver, and won't limit itself to
a local DNS cache.

In other words, as long as DNS isn't broken, it'll go through the
whole standard DNS resolution process, and you should get an answer
for any (valid) domainname given, whether or not anyone on the machine
has tried to hit it lately.  I'm not aware of any way to request
gethostbyname() query a cache only, at least not on Solaris.  The same
may well be true for gethostname() on MacOS, but I don't know.

There is /usr/sbin/nscd, which, though after my time as a sysadmin,
apparently is a local cacheing daemon for various nameservices.  It
seems to be available for both Solaris and Linux.  If it is running
and enabled for the hosts database, gethostbyname() will hit nscd's
cache before querying the nameservers from /etc/resolv.conf, but I
can't immediately find a way to query *just* nscd's cache.  You can
get statistics on cache hits with the -g option, but it doesn't list
the contents.

[nscd seems kind of scary; not only does it have its own configuration
options for things like TTL, which can override the settings from the
authoritative nameserver, but there's also the option to have per-user
caches for at least some databases.  Sounds like a nightmare from both
administrative and security perspectives.]

There's also the fact that there are lots of ways to implement a local
DNS cache on UNIX or Linux systems, with probably vastly different
methods (if any) to query just that local cache.  With such a generic
test name, the implication is that a proper implementation would have
to account for any of them...

> Mac OS:
>
> To view the DNS cache from the command line: dscacheutil -cachedump
> -entries host
> http://developer.apple.com/mac/library/documentation/Darwin/Reference/M
> anPages/man1/dscacheutil.1.html
>
> Access the DNS cache with a function call: gethostbyname
> http://developer.apple.com/mac/library/documentation/Darwin/Reference/M
> anPages/man3/gethostbyname.3.html
>
> Also, I have attached a copy of the proposed changes to the
> independent schema for your review.  Would the addition of this test
> to the OVAL Language be beneficial to the community?  Is there
> anything missing?  Please let me know if there any questions,
> comments, or concerns about this proposal.

As I said, I can see some real cases where understanding a system's
view of DNS could be useful and important.  But it does seem like
there are some issues here.

Cheers,

--Woj                  Matthew N. Wojcik                 [hidden email]
781 271-8056 office                        Remediation Standardization
617 872-6247 mobile                                   CCE Project Lead
[and OVAL Moderator Emeritus]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Add a DNS Cache Test to the Independent Component Schema

Jon Baker
Administrator
As I noted earlier this week in the announcement of 5.7 draft 2 the proposed ind-def:dnscache_test still needs additional consideration. At the moment I think there are two open questions related to this test that I would appreciate community feedback on. I would like to make sure that the test is both supportable by the organizations that will need to implement it and that the test meets the needs of those that would like to use it to examine end systems.

1- Will the dnscache_test be reasonably supportable on unix systems?
We realize that on windows it is fairly straight forward to query a host's dns cache. There is one set of documented windows apis that can be used fairly reliably. However, on unix systems this is not the case. From one unix OS to the next there might be a significantly different method for retrieving dnscache information, or worse no method at all. This inconsistency leads me to question how supportable this test is on unix systems for those that need to implement it and it concerns me that content authors that want to use this new test on unix systems will be disappointed with the results. These concerns lead me to question whether it is really appropriate to have the new dnscache_test in the independent schema. Perhaps it would be better to put the test in the windows schema and not add the test to the unix schema? If we take this approach we could always later add the test to the unix schema in version 5.8 or later and we would be assured that the test is both supportable from an implementation perspective and would likely meet the needs of content authors.


2- We received a request to add in a timestamp and a time to live fields when examining the dns cache on windows. To the best of my knowledge there is no such thing as a timestamp that records the time an entry was added to a local host's dns cache. In my previous email I suggested that we would add these two fields to a windows version of the test only because I thought that windows provided this timestamp and unix systems did not, but so far I have not been able to find such a field in the windows dns cache related api documentation. Additionally, it has been pointed out to me that the time to live field would certainly make sense across dns cache implementations beyond just the implementation on windows. This leads me to suggest that the next draft of version 5.7 should include a time to live field in the dnscache_state and dnscache_item regardless of what is decided with the first issue I raised.


Any comments of feedback on this test would be greatly appreciated.

Without further input our default action will be to move the proposed test to the windows-definitions-schema and add in a time to live field.

Thanks,

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]


>-----Original Message-----
>From: Wojcik, Matthew N. [mailto:[hidden email]]
>Sent: Thursday, January 28, 2010 6:07 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Proposal to Add a DNS Cache Test to
>the Independent Component Schema
>
>Wow, I haven't gotten involved in an OVAL discussion in a long time.
>And my hands-on experience with DNS is out of date enough that I'm
>probably on thin ice in places here.  That said...
>
>Comments inline.
>
>On Jan 28, 2010, at 12:22 PM, "Haynes, Dan" <[hidden email]> wrote:
>
>> We would like to propose a new test for the OVAL Language that,
>> given a domain name, would collect all the IP addresses stored in
>> the DNS cache on the local system.  This test would apply to all
>> platforms and would be placed in the independent component schema.
>
>I'm a bit worried that the functioning of DNS cacheing isn't universal
>enough to really work in the independent schema.  It may be more
>appropriate to create platform-specific tests.  After all, we have
>separate Windows and Unix tests for process info and file info,
>because even though there are shared concepts, the details are
>different enough to merit separate tests.
>
>For one thing, the ability may not always exist to specifically query
>a DNS cache local to the particular end system.  On some platforms,
>with a simple operation you may only be able to find out what the
>resolving routines return for a given record.  Determining the
>provenance of that information may be a very complicated multi-step
>process, perhaps more complicated than is really ideal for a simple
>OVAL test.  More on that in the system-specific sections below.
>
>> The dnscache_object will consist of a single domain_name entity that
>> will be used to guide the collection of the domain names stored in
>> the DNS cache.  The dnscache_object would be able to collect a
>> single domain name, a subset of the domain names, or all of the
>> domain names present in the DNS cache.  The dnscache_state will
>> contain a domain_name entity that can be used to check the value of
>> a domain_name and an ip_address entity that can be used to the check
>> the value of the IP address(es) associated with the domain name.
>> The dnscache_item will contain a domain_name entity that will
>> represent a domain name stored in the DNS cache and it will have
>> zero or more ip_address entities that will each represent an IP
>> address associated with that domain name.
>
>My other reservations notwithstanding, I can imagine a number of
>scenarios where it might be important to know what DNS information a
>system is seeing.  And I saw Jon's message about not intending a
>general-purpose DNS resolver test.  I think once you've got the
>ability to look at A records, though, all the other DNS record types
>are going to be wanted very quickly.  Why not just build them in now?
>
>> The following provides links to additional information that would be
>> useful if this test was to be implemented.
>>
>> Windows:
>>
>> To view the DNS cache from the command line: ipconfig /displaydns |
>> more
>> http://technet.microsoft.com/en-us/library/cc758108(WS.10).aspx
>>
>> Access the DNS cache with a function call: DnsQuery
>> http://msdn.microsoft.com/en-us/library/ms682016(VS.85).aspx
>
>I don't really know anything about DNS resolution and cacheing on
>Windows, so I probably shouldn't comment here.  The test as propsed
>may be fine for Windows.  Looking briefly at the documentation for
>DnsQuery, it looks like DNS_QUERY_NO_WIRE_QUERY should be set as an
>option, at least post-Windows 2000.  See
>
>http://msdn.microsoft.com/en-us/library/cc982162(VS.85).aspx
>
>> Linux/Solaris:
>>
>> To view the DNS cache from the command line: getent hosts
>> <domain_name>
>> http://linux.die.net/man/1/getent
>> http://www.softpanorama.org/Net/Netutils/solaris_getent.shtml
>>
>> Access the DNS cache with a function call: gethostbyname
>> http://linux.die.net/man/3/gethostbyname
>> http://ibgwww.colorado.edu/~lessem/psyc5112/usail/man/solaris/gethostby
>> name.3.html
>
>I think these aren't going to give you what you want, as I understand
>it.  On a Solaris 10 box I have access to, where the hosts entry in
>/etc/nsswitch.conf is set to "files dns", "getent hosts" returns the
>contents of the hosts file.  "getent hosts <domain_name>" invokes
>gethostbyname(), which is the DNS resolver, and won't limit itself to
>a local DNS cache.
>
>In other words, as long as DNS isn't broken, it'll go through the
>whole standard DNS resolution process, and you should get an answer
>for any (valid) domainname given, whether or not anyone on the machine
>has tried to hit it lately.  I'm not aware of any way to request
>gethostbyname() query a cache only, at least not on Solaris.  The same
>may well be true for gethostname() on MacOS, but I don't know.
>
>There is /usr/sbin/nscd, which, though after my time as a sysadmin,
>apparently is a local cacheing daemon for various nameservices.  It
>seems to be available for both Solaris and Linux.  If it is running
>and enabled for the hosts database, gethostbyname() will hit nscd's
>cache before querying the nameservers from /etc/resolv.conf, but I
>can't immediately find a way to query *just* nscd's cache.  You can
>get statistics on cache hits with the -g option, but it doesn't list
>the contents.
>
>[nscd seems kind of scary; not only does it have its own configuration
>options for things like TTL, which can override the settings from the
>authoritative nameserver, but there's also the option to have per-user
>caches for at least some databases.  Sounds like a nightmare from both
>administrative and security perspectives.]
>
>There's also the fact that there are lots of ways to implement a local
>DNS cache on UNIX or Linux systems, with probably vastly different
>methods (if any) to query just that local cache.  With such a generic
>test name, the implication is that a proper implementation would have
>to account for any of them...
>
>> Mac OS:
>>
>> To view the DNS cache from the command line: dscacheutil -cachedump
>> -entries host
>> http://developer.apple.com/mac/library/documentation/Darwin/Reference/M
>> anPages/man1/dscacheutil.1.html
>>
>> Access the DNS cache with a function call: gethostbyname
>> http://developer.apple.com/mac/library/documentation/Darwin/Reference/M
>> anPages/man3/gethostbyname.3.html
>>
>> Also, I have attached a copy of the proposed changes to the
>> independent schema for your review.  Would the addition of this test
>> to the OVAL Language be beneficial to the community?  Is there
>> anything missing?  Please let me know if there any questions,
>> comments, or concerns about this proposal.
>
>As I said, I can see some real cases where understanding a system's
>view of DNS could be useful and important.  But it does seem like
>there are some issues here.
>
>Cheers,
>
>--Woj                  Matthew N. Wojcik                 [hidden email]
>781 271-8056 office                        Remediation Standardization
>617 872-6247 mobile                                   CCE Project Lead
>[and OVAL Moderator Emeritus]

Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Add a DNS Cache Test to the Independent Component Schema

Danny Haynes
Administrator
We haven't received any objections regarding this proposal.  Therefore, we will move ahead with Jon's proposal.  This means that we will remove the dnscache_test from the independent schema and place the dnscache_test into the windows and unix schemas.  We will also add the ttl (time to live) entity to the dnscache_state and dnscache_item in both the windows and unix schemas.  These changes will be available in the Version 5.7 Release Candidate.    

Also, as Jon said, there was a request for a timestamp field indicating when the entry was added to the DNS cache and we have not been able to find a way to retrieve this information.  This is still the case.  As a result, we will continue to look for a way to retrieve this information, but will defer the addition of a timestamp field until after Version 5.7.  The timestamp field can easily be added to Version 5.8 if it is discovered that the timestamp information can be retrieved.  

Lastly, as we have been spending additional time working on this test, it seems that it could be useful to see what DNS information a system is seeing.   Are there any thoughts on this?  

Thanks,

Danny

>-----Original Message-----
>From: Baker, Jon [mailto:[hidden email]]
>Sent: Saturday, February 20, 2010 8:45 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Proposal to Add a DNS Cache Test to the
>Independent Component Schema
>
>As I noted earlier this week in the announcement of 5.7 draft 2 the proposed
>ind-def:dnscache_test still needs additional consideration. At the moment I
>think there are two open questions related to this test that I would appreciate
>community feedback on. I would like to make sure that the test is both
>supportable by the organizations that will need to implement it and that the
>test meets the needs of those that would like to use it to examine end systems.
>
>1- Will the dnscache_test be reasonably supportable on unix systems?
>We realize that on windows it is fairly straight forward to query a host's dns
>cache. There is one set of documented windows apis that can be used fairly
>reliably. However, on unix systems this is not the case. From one unix OS to
>the next there might be a significantly different method for retrieving
>dnscache information, or worse no method at all. This inconsistency leads me to
>question how supportable this test is on unix systems for those that need to
>implement it and it concerns me that content authors that want to use this new
>test on unix systems will be disappointed with the results. These concerns lead
>me to question whether it is really appropriate to have the new dnscache_test
>in the independent schema. Perhaps it would be better to put the test in the
>windows schema and not add the test to the unix schema? If we take this
>approach we could always later add the test to the unix schema in version 5.8
>or later and we would be assured that the test is both supportable from an
>implementation perspective and would likely meet the needs of content authors.
>
>
>2- We received a request to add in a timestamp and a time to live fields when
>examining the dns cache on windows. To the best of my knowledge there is no
>such thing as a timestamp that records the time an entry was added to a local
>host's dns cache. In my previous email I suggested that we would add these two
>fields to a windows version of the test only because I thought that windows
>provided this timestamp and unix systems did not, but so far I have not been
>able to find such a field in the windows dns cache related api documentation.
>Additionally, it has been pointed out to me that the time to live field would
>certainly make sense across dns cache implementations beyond just the
>implementation on windows. This leads me to suggest that the next draft of
>version 5.7 should include a time to live field in the dnscache_state and
>dnscache_item regardless of what is decided with the first issue I raised.
>
>
>Any comments of feedback on this test would be greatly appreciated.
>
>Without further input our default action will be to move the proposed test to
>the windows-definitions-schema and add in a time to live field.
>
>Thanks,
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>
>>-----Original Message-----
>>From: Wojcik, Matthew N. [mailto:[hidden email]]
>>Sent: Thursday, January 28, 2010 6:07 PM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] Proposal to Add a DNS Cache Test to
>>the Independent Component Schema
>>
>>Wow, I haven't gotten involved in an OVAL discussion in a long time.
>>And my hands-on experience with DNS is out of date enough that I'm
>>probably on thin ice in places here.  That said...
>>
>>Comments inline.
>>
>>On Jan 28, 2010, at 12:22 PM, "Haynes, Dan" <[hidden email]> wrote:
>>
>>> We would like to propose a new test for the OVAL Language that,
>>> given a domain name, would collect all the IP addresses stored in
>>> the DNS cache on the local system.  This test would apply to all
>>> platforms and would be placed in the independent component schema.
>>
>>I'm a bit worried that the functioning of DNS cacheing isn't universal
>>enough to really work in the independent schema.  It may be more
>>appropriate to create platform-specific tests.  After all, we have
>>separate Windows and Unix tests for process info and file info,
>>because even though there are shared concepts, the details are
>>different enough to merit separate tests.
>>
>>For one thing, the ability may not always exist to specifically query
>>a DNS cache local to the particular end system.  On some platforms,
>>with a simple operation you may only be able to find out what the
>>resolving routines return for a given record.  Determining the
>>provenance of that information may be a very complicated multi-step
>>process, perhaps more complicated than is really ideal for a simple
>>OVAL test.  More on that in the system-specific sections below.
>>
>>> The dnscache_object will consist of a single domain_name entity that
>>> will be used to guide the collection of the domain names stored in
>>> the DNS cache.  The dnscache_object would be able to collect a
>>> single domain name, a subset of the domain names, or all of the
>>> domain names present in the DNS cache.  The dnscache_state will
>>> contain a domain_name entity that can be used to check the value of
>>> a domain_name and an ip_address entity that can be used to the check
>>> the value of the IP address(es) associated with the domain name.
>>> The dnscache_item will contain a domain_name entity that will
>>> represent a domain name stored in the DNS cache and it will have
>>> zero or more ip_address entities that will each represent an IP
>>> address associated with that domain name.
>>
>>My other reservations notwithstanding, I can imagine a number of
>>scenarios where it might be important to know what DNS information a
>>system is seeing.  And I saw Jon's message about not intending a
>>general-purpose DNS resolver test.  I think once you've got the
>>ability to look at A records, though, all the other DNS record types
>>are going to be wanted very quickly.  Why not just build them in now?
>>
>>> The following provides links to additional information that would be
>>> useful if this test was to be implemented.
>>>
>>> Windows:
>>>
>>> To view the DNS cache from the command line: ipconfig /displaydns |
>>> more
>>> http://technet.microsoft.com/en-us/library/cc758108(WS.10).aspx
>>>
>>> Access the DNS cache with a function call: DnsQuery
>>> http://msdn.microsoft.com/en-us/library/ms682016(VS.85).aspx
>>
>>I don't really know anything about DNS resolution and cacheing on
>>Windows, so I probably shouldn't comment here.  The test as propsed
>>may be fine for Windows.  Looking briefly at the documentation for
>>DnsQuery, it looks like DNS_QUERY_NO_WIRE_QUERY should be set as an
>>option, at least post-Windows 2000.  See
>>
>>http://msdn.microsoft.com/en-us/library/cc982162(VS.85).aspx
>>
>>> Linux/Solaris:
>>>
>>> To view the DNS cache from the command line: getent hosts
>>> <domain_name>
>>> http://linux.die.net/man/1/getent
>>> http://www.softpanorama.org/Net/Netutils/solaris_getent.shtml
>>>
>>> Access the DNS cache with a function call: gethostbyname
>>> http://linux.die.net/man/3/gethostbyname
>>> http://ibgwww.colorado.edu/~lessem/psyc5112/usail/man/solaris/gethostby
>>> name.3.html
>>
>>I think these aren't going to give you what you want, as I understand
>>it.  On a Solaris 10 box I have access to, where the hosts entry in
>>/etc/nsswitch.conf is set to "files dns", "getent hosts" returns the
>>contents of the hosts file.  "getent hosts <domain_name>" invokes
>>gethostbyname(), which is the DNS resolver, and won't limit itself to
>>a local DNS cache.
>>
>>In other words, as long as DNS isn't broken, it'll go through the
>>whole standard DNS resolution process, and you should get an answer
>>for any (valid) domainname given, whether or not anyone on the machine
>>has tried to hit it lately.  I'm not aware of any way to request
>>gethostbyname() query a cache only, at least not on Solaris.  The same
>>may well be true for gethostname() on MacOS, but I don't know.
>>
>>There is /usr/sbin/nscd, which, though after my time as a sysadmin,
>>apparently is a local cacheing daemon for various nameservices.  It
>>seems to be available for both Solaris and Linux.  If it is running
>>and enabled for the hosts database, gethostbyname() will hit nscd's
>>cache before querying the nameservers from /etc/resolv.conf, but I
>>can't immediately find a way to query *just* nscd's cache.  You can
>>get statistics on cache hits with the -g option, but it doesn't list
>>the contents.
>>
>>[nscd seems kind of scary; not only does it have its own configuration
>>options for things like TTL, which can override the settings from the
>>authoritative nameserver, but there's also the option to have per-user
>>caches for at least some databases.  Sounds like a nightmare from both
>>administrative and security perspectives.]
>>
>>There's also the fact that there are lots of ways to implement a local
>>DNS cache on UNIX or Linux systems, with probably vastly different
>>methods (if any) to query just that local cache.  With such a generic
>>test name, the implication is that a proper implementation would have
>>to account for any of them...
>>
>>> Mac OS:
>>>
>>> To view the DNS cache from the command line: dscacheutil -cachedump
>>> -entries host
>>> http://developer.apple.com/mac/library/documentation/Darwin/Reference/M
>>> anPages/man1/dscacheutil.1.html
>>>
>>> Access the DNS cache with a function call: gethostbyname
>>> http://developer.apple.com/mac/library/documentation/Darwin/Reference/M
>>> anPages/man3/gethostbyname.3.html
>>>
>>> Also, I have attached a copy of the proposed changes to the
>>> independent schema for your review.  Would the addition of this test
>>> to the OVAL Language be beneficial to the community?  Is there
>>> anything missing?  Please let me know if there any questions,
>>> comments, or concerns about this proposal.
>>
>>As I said, I can see some real cases where understanding a system's
>>view of DNS could be useful and important.  But it does seem like
>>there are some issues here.
>>
>>Cheers,
>>
>>--Woj                  Matthew N. Wojcik                 [hidden email]
>>781 271-8056 office                        Remediation Standardization
>>617 872-6247 mobile                                   CCE Project Lead
>>[and OVAL Moderator Emeritus]