DNS resolution for hhs.gov

Sat Apr 15 19:31:18 UTC 2023

Always love your in-depth analysis. Thanks, Mark.  :)

On 4/14/23 4:40 PM, Mark Andrews wrote:
> 
> 
>> On 15 Apr 2023, at 02:41, Doug Barton <dougb at dougbarton.us> wrote:
>>
>> Responses in line below.
>>
>> Doug
>>
>>
>> On 4/11/23 8:12 AM, Samuel Jackson wrote:
>>> I wanted to run this by everyone to make sure I am not the one losing my mind over this.
>>> A dig +trace cob.cms.hhs.gov <http://cob.cms.hhs.gov> fails for me as it looks like the NS for hhs.gov <http://hhs.gov> does not seem to resolve the hostname.
>>
>> They shouldn't, since cms.hhs.gov is a delegated subzone. (Also, resolve is the wrong term, since those are authoritative servers, not resolvers.) The hhs.gov name servers are not authoritative for the cms.hhs.gov zone.
>>
>> Using `dig +trace cob.cms.hhs.gov` worked for me just now, so it's possible that they fixed something in response to Mark's message.
> 
> No, they haven’t.
> 
> The problem is that QNAME minimisation asks _.<domain>/A queries to elicit referrals and the servers for hhs.gov don’t respond to them.  Optimally we would ask NS queries but there are delegations where the child NS RRset are complete garbage and in this case hss.gov don’t respond to some of them either over TCP as was shown in the earlier messages.
> 
> Telling named to only use TCP with the servers for hss.gov should help.
> 
> e.g.
> server 158.74.30.99 { tcp-only yes; };
> 
> For 'dig +trace’ the addresses of the nameservers are looked up and glue is not good enough.  When named
> attempts to resolve rh202ns2.355.dhhs.gov and similar the queries it makes do not get responses.
> 
> % dig rh202ns2.355.dhhs.gov @158.74.30.99
> 
> ; <<>> DiG 9.19.11-dev <<>> rh202ns2.355.dhhs.gov @158.74.30.99
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50815
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 2636ce7eeb438b88fe1b0a2d6439dcce550e6799df6049a8 (good)
> ;; QUESTION SECTION:
> ;rh202ns2.355.dhhs.gov. IN A
> 
> ;; ANSWER SECTION:
> rh202ns2.355.dhhs.gov. 9000 IN A 158.74.30.99
> 
> ;; Query time: 328 msec
> ;; SERVER: 158.74.30.99#53(158.74.30.99) (UDP)
> ;; WHEN: Sat Apr 15 09:07:58 AEST 2023
> ;; MSG SIZE  rcvd: 94
> 
> % dig _.355.dhhs.gov @158.74.30.99
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> 
> ; <<>> DiG 9.19.11-dev <<>> _.355.dhhs.gov @158.74.30.99
> ;; global options: +cmd
> ;; no servers could be reached
> 
> % dig 355.dhhs.gov ns @158.74.30.99
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> ;; communications error to 158.74.30.99#53: timed out
> 
> ; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov ns @158.74.30.99
> ;; global options: +cmd
> ;; no servers could be reached
> 
> % dig 355.dhhs.gov ns @158.74.30.99 +tcp
> 
> ; <<>> DiG 9.19.11-dev <<>> 355.dhhs.gov ns @158.74.30.99 +tcp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51550
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 86462f55438e987dd7cd37926439dd174d9cf5907438ce51 (good)
> ;; QUESTION SECTION:
> ;355.dhhs.gov. IN NS
> 
> ;; AUTHORITY SECTION:
> dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021761 1200 300 2419200 3600
> 
> ;; Query time: 351 msec
> ;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
> ;; WHEN: Sat Apr 15 09:09:11 AEST 2023
> ;; MSG SIZE  rcvd: 137
> 
> % dig _.355.dhhs.gov @158.74.30.99 +tcp
> 
> ; <<>> DiG 9.19.11-dev <<>> _.355.dhhs.gov @158.74.30.99 +tcp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19166
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 22078767daaad75caba70a826439dd1dcc25d44396d38240 (good)
> ;; QUESTION SECTION:
> ;_.355.dhhs.gov. IN A
> 
> ;; AUTHORITY SECTION:
> dhhs.gov. 3600 IN SOA rh120ns1.368.dhhs.gov. hostmaster.psc.hhs.gov. 2023021761 1200 300 2419200 3600
> 
> ;; Query time: 244 msec
> ;; SERVER: 158.74.30.99#53(158.74.30.99) (TCP)
> ;; WHEN: Sat Apr 15 09:09:17 AEST 2023
> ;; MSG SIZE  rcvd: 139
> 
> %
> 
> At this stage I don’t know if the email I sent earlier has even reached the administrator responsible.  I haven’t seen a response.  It could still be queued on our outbound SMTP servers trying to resolve MX records or their targets.
> 
> Also if named times out asking all 8 servers for an in-scope name why should expect to get an answer for a different in-scope name? Playing silly games by not answering consistently just causes issues.
> 
>>> However dig +trace cms.hhs.gov <http://cms.hhs.gov> resolves and so does
>>
>> That makes sense, delegated sub zone.  :)
>>
>>> dig +trace eclkc.ohs.acf.hhs.gov <http://eclkc.ohs.acf.hhs.gov>
>>
>> No delegated sub zones in the path here, so the hhs.gov name servers are authoritative for this host.
>>
>>> However if I simply ask my local resolver to resolve cob.cms.hhs.gov <http://cob.cms.hhs.gov>, it works. Any thoughts on why this is the case?
>>
>> Because it's getting the answer from the child zone (cms) like it should.
>>
>> I'm sort of curious about what `dig +trace` results you received originally that made you believe that you weren't getting the right response. Are you currently seeing what you expect to see?
> 