[dns-operations] fun with .gov

[Rodney Joffe]

Michael,

nic.gov was the last host that responded with data.

whois.dotgov.gov has never responded for us.

If anyone finds a working port 43 server for .gov, let us know :-)


On Jan 13, 2010, at 7:19 PM, Michael Sinatra wrote:

> Over the past week, I have seen three problems related to the GOV  
> TLD (mostly nih.gov):
>
> 1. whois b0rked:
>
> On MacOS X and *bsd systems, 'whois xxx.gov' attempts to contact the  
> server at gov.whois-servers.net.  That used to work, but at some  
> point, I started getting the following:
>
> [sonic] ~> whois nih.gov
> whois: gov.whois-servers.net: Non-recoverable failure in name  
> resolution
>
> [sonic] ~> dig gov.whois-servers.net
>
> ; <<>> DiG 9.6.1-P2 <<>> gov.whois-servers.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10480
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;gov.whois-servers.net.         IN      A
>
> ;; ANSWER SECTION:
> gov.whois-servers.net.  511     IN      CNAME   nic.gov.
>
> ;; AUTHORITY SECTION:
> nic.gov.                38311   IN      SOA     dnssec7.datamtn.com.  
> support.datamtn.com. 2009123014 10800 3600 604800 38400
>
> It looks like there is no longer an A record for nic.gov.
>
> There is still an A record for whois.nic.gov (which Linux whois  
> clients tend to use by default), but I get a timeout when I try to  
> do a whois query to that server.  I am going to pass this on to  
> Centergate (maintainers of whois-servers.net) and datamtn.com, but I  
> thought I would just point it out here.
>
> 2. Problems in nih.gov: nlm.nih.gov mis-signed last week: Last week,  
> the nlm.nih.gov zone was missing DNSSEC records on 3 of its 5  
> authoritative nameservers.  lhcns1.nlm.nih.gov and  
> lhcns2.nlm.nih.gov both had DNSKEYs and signed data in their  
> nlm.nih.gov zones; but the parent nameservers (also authoritative)  
> ns.nih.gov and ns[23].nih.gov did not.  A DS record for nlm.nih.gov  
> did exist in nih.gov, so this broke the zone nlm.nih.gov (and all  
> subzones) for validation.  This was fixed late last week, although  
> lhcns[12] have different signature validity dates.  (Perhaps the  
> signing processes are separate on those two machines?)  However, the  
> zone does now validate.
>
> A number of people on the Internet2 DNSSEC mailing list helped  
> diagnose this problem.
>
> 3. Problems in nih.gov: niehs.nih.gov broken: This problem is still  
> ongoing.  Casey Deccio of Sandia National Lab diagnosed this problem  
> and posted it to dnssec at internet2.edu.  It's another case where the  
> parent zone nameservers (ns.nih.gov and ns[23].nih.gov,  
> authoritative for nih.gov) are also authoritative for the child zone  
> niehs.nih.gov.  In this case, there are no delegation (NS) records,  
> nor are there DS records for niehs.nih.gov in nih.gov.  In a non- 
> DNSSEC-validation situation, one can (mostly) get away with this  
> setup because the authoritative nameservers load the sub-zone and  
> have the NS records there.  In a validation situation, where one  
> askes the parent nameserver for DS records, the parent nameserver  
> will reply with NXDOMAIN instead of NOERROR with an empty answer  
> section.  The result is a validation (and resolution) failure, even  
> though niehs.nih.gov isn't intended to be signed or validated.
>
> Michael Contino of Penn State has been trying to track down this  
> problem with the contractor who provides DNS for niehs.nih.gov, but  
> that doesn't seem to have gotten anywhere yet.  The fix really needs  
> to be in nih.gov, not in niehs.nih.gov.
>
> Because these problems have surfaced just recently, I suspect that  
> the trust anchor DS record for nih.gov has recently been added to  
> the gov zone.  Can anyone with visibility in the GOV TLD operation  
> confirm?  If that's the case, it serves as a reminder to test your  
> signed zone before you start spreading your trust anchors.  There  
> are a number of us in EDU and GOV who are doing validation, and this  
> is breaking things for us. Also if anyone knows of a clueful contact  
> in nih.gov, let me know.
>
> To everyone else, we need to be careful to have delegation NS  
> records in the parent zone even/especially if the parent zone is  
> signed and the child is not.
>
> michael
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>