Discuss mailing list

[Peter McCann <mccap AT freeovernetfoundation.org>]

I'm still having trouble understanding why we would need to look at the
whole zone.  Wouldn't it be enough to make sure that the NS glue records
returned by the delegation point at the parent TLD get set to the servers
that the protected domain wanted?  It's up to them to maintain the data
on that server in whatever manner they want.

To be really secure, we should use DNSSEC and allow the owner to
configure a DS record using their public key.  This would require arranging
for authentication of updates to the DS and NS glue records.

Maybe the heuristics you give below about monitoring the list of NS
records would be a good trigger for an investigation, but you should
probably get in touch with the owner OOB to confirm that they didn't
just forget to update OpenNIC when they made a (wanted) change.

-Pete

On Sun, Mar 6, 2011 at 4:55 PM, Jeff Taylor <shdwdrgn AT sourpuss.net> wrote:
> Some quick notes on my concept for the monitoring code (related to
> domains)...
>
> If a site owner requests OpenNic monitoring, we can arrange to have access
> to their zone data.  Any differences between what is expected and what an
> ICANN query returns would throw up a flag and initiate the redirect warning
> page.
>
> If we are monitoring a site without cooperation by the owner, things become
> tricky.  We need to recognize what constitutes a legitimate change by the
> owner, and what looks more like a hostile takeover.  Towards this, I have a
> few ideas.  Obviously a combination of test methods would provide for the
> most accurate automated response...
> - Flag if there is a large percentage of the nameservers change.  This is a
> simple rule comparing the number of NS records that changed, so we flag if
> more than xx% of the nameservers changed.  This rule can be falsely
> triggered if the site had 2 nameservers and added 4 new ones.
> - I could create a rule that only flags on a specific event, such as none of
> the previous nameservers are present in the new list.  Very unlikely to
> happen in the normal course of a website, but of course this and the
> previous idea can be falsely triggered if the website completely changes
> hosts or providers.
> - Maintain a blacklist of IPs.  We can probably find a maintained listing of
> US-government controlled IP space, and any changes which points DNS queries
> to an IP from this list would immediately trigger a flag.
> - Large structural changes to the DNS record.  If a domain previously
> contained a variety of NS, MX, and TXT records, plus some subdomains, and
> then suddenly has a blank slate except for two NS records, this could send
> off a warning flag.
>
> The monitoring itself could actually be very simple -- just pull a list of
> nameservers for a domain and compare that to what we saw last time, but some
> methods of detecting tampering would require a more detailed look at the
> zone.


-- 
Pete McCann <mccap AT freeovernetfoundation.org>
pgp 0x9FAF5668