DNS resolution for hhs.gov
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 fails for me as it looks like the NS for hhs.gov does not seem to resolve the hostname. However dig +trace cms.hhs.gov resolves and so does dig +trace eclkc.ohs.acf.hhs.gov However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it works. Any thoughts on why this is the case? Thanks,
On Tue 2023-04-11 08:12:35-0700 Samuel wrote:
A dig +trace cob.cms.hhs.gov fails for me as it looks like the NS for hhs.gov does not seem to resolve the hostname.
However dig +trace cms.hhs.gov resolves and so does dig +trace eclkc.ohs.acf.hhs.gov
However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it works. Any thoughts on why this is the case?
Looks like their v6 resolvers are failing, but v4 works fine. DNSVis.net is a good place to check nameserver issues.. -- Regards, Robert -- Robert Story USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division
Thanks, Yeah, I did run it on that site too. What I am trying to figure out is why trace does not seem to work. Our DNS servers perform queries similar to what trace would do. They fail to resolve the hostname. They do not use another local resolver. Thanks, On Tue, Apr 11, 2023 at 9:33 AM Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Apr 11, 2023 at 12:16:36PM -0400, Robert Story <rstory@ant.isi.edu> wrote a message of 22 lines which said:
DNSVis.net is a good place to check nameserver issues..
DNSViZ.net. Yes, great service.
The nameservers are not answering all in scope questions being sent to the servers. Something is blocking or not generating NXDOMAIN responses. This impacts on QNAME minimisation queries that usually elicit a NXDOMAIN response. This happens irrespective of DNSSEC records being requested so I doubt that it is a fragmentation issue. Both _.dhhs.gov <http://dhhs.gov/> and foobar.dhhs.gov <http://foobar.dhhs.gov/> time out but dhhs.gov <http://dhhs.gov/> itself doesn’t. % dig _.dhhs.gov @158.74.30.103 +dnssec ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ; <<>> DiG 9.19.11-dev <<>> _.dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; no servers could be reached % dig dhhs.gov @158.74.30.103 +dnssec ; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18125 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: d939ecfdb6cd2d902678cca26435eb2dd6fcebd65fe5c58f (good) ;; QUESTION SECTION: ;dhhs.gov. IN A ;; ANSWER SECTION: dhhs.gov. 9000 IN A 52.7.111.176 dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 11710 dhhs.gov. YCEsecATdJEHs3OtxQs/kE2A/37/mzgUpGLzQwrPP9xqaGmBq2mDteKx QyUnh0JuURBq0Qy1htxsOD9kX4dxSxUNCEO7/KHw0AOoIbnh2+GL8kc3 jKB2jkcN+whA9+CqThto020nLSCXcgdm7qOfyNBUFICoYNtVrd7/lLCJ kho= dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 21469 dhhs.gov. OkEdR/ofhV+JogwAkZtLmHyxn3pK2E4zaGUV786kKbtQrI6SzetCk+sC Db3W0LrYRZy1BEqqxZeRnLXVEjyyyKfnYMRPtoP3sCTLPuuDeu8oDmhw eniXLbJ10od6YWywgQDl2bYrTLEt6R8+TGG7up446TGgRk9wOV/uU2Jb d+U= ;; Query time: 308 msec ;; SERVER: 158.74.30.103#53(158.74.30.103) (UDP) ;; WHEN: Wed Apr 12 09:20:13 AEST 2023 ;; MSG SIZE rcvd: 417 % dig foobar.dhhs.gov @158.74.30.103 +dnssec ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; no servers could be reached % dig foobar.dhhs.gov @158.74.30.103 ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 ;; global options: +cmd ;; no servers could be reached %
On 12 Apr 2023, at 01:12, Samuel Jackson <bobin.public@gmail.com> 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 fails for me as it looks like the NS for hhs.gov does not seem to resolve the hostname.
However dig +trace cms.hhs.gov resolves and so does dig +trace eclkc.ohs.acf.hhs.gov
However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it works. Any thoughts on why this is the case?
Thanks,
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Interestingly enough, the company behind this mess decided to sign it: bjorn@canardo:~$ dig dhhs.gov @158.74.30.99 +nsid|grep NSID ; NSID: 4c 65 69 64 6f 73 20 62 75 69 6c 64 20 57 2e 56 45 52 4e 41 20 32 30 32 33 ("Leidos build W.VERNA 2023") Guessing this was done by "security professionals" from https://www.leidos.com/ Bjørn Mark Andrews <marka@isc.org> writes:
The nameservers are not answering all in scope questions being sent to the servers. Something is blocking or not generating NXDOMAIN responses. This impacts on QNAME minimisation queries that usually elicit a NXDOMAIN response. This happens irrespective of DNSSEC records being requested so I doubt that it is a fragmentation issue.
Both _.dhhs.gov <http://dhhs.gov/> and foobar.dhhs.gov <http://foobar.dhhs.gov/> time out but dhhs.gov <http://dhhs.gov/> itself doesn’t.
% dig _.dhhs.gov @158.74.30.103 +dnssec ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out
; <<>> DiG 9.19.11-dev <<>> _.dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; no servers could be reached
% dig dhhs.gov @158.74.30.103 +dnssec
; <<>> DiG 9.19.11-dev <<>> dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18125 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: d939ecfdb6cd2d902678cca26435eb2dd6fcebd65fe5c58f (good) ;; QUESTION SECTION: ;dhhs.gov. IN A
;; ANSWER SECTION: dhhs.gov. 9000 IN A 52.7.111.176 dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 11710 dhhs.gov. YCEsecATdJEHs3OtxQs/kE2A/37/mzgUpGLzQwrPP9xqaGmBq2mDteKx QyUnh0JuURBq0Qy1htxsOD9kX4dxSxUNCEO7/KHw0AOoIbnh2+GL8kc3 jKB2jkcN+whA9+CqThto020nLSCXcgdm7qOfyNBUFICoYNtVrd7/lLCJ kho= dhhs.gov. 9000 IN RRSIG A 8 2 9000 20230416000149 20230410230149 21469 dhhs.gov. OkEdR/ofhV+JogwAkZtLmHyxn3pK2E4zaGUV786kKbtQrI6SzetCk+sC Db3W0LrYRZy1BEqqxZeRnLXVEjyyyKfnYMRPtoP3sCTLPuuDeu8oDmhw eniXLbJ10od6YWywgQDl2bYrTLEt6R8+TGG7up446TGgRk9wOV/uU2Jb d+U=
;; Query time: 308 msec ;; SERVER: 158.74.30.103#53(158.74.30.103) (UDP) ;; WHEN: Wed Apr 12 09:20:13 AEST 2023 ;; MSG SIZE rcvd: 417
% dig foobar.dhhs.gov @158.74.30.103 +dnssec ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out
; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 +dnssec ;; global options: +cmd ;; no servers could be reached
% dig foobar.dhhs.gov @158.74.30.103 ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out ;; communications error to 158.74.30.103#53: timed out
; <<>> DiG 9.19.11-dev <<>> foobar.dhhs.gov @158.74.30.103 ;; global options: +cmd ;; no servers could be reached
%
On 12 Apr 2023, at 01:12, Samuel Jackson <bobin.public@gmail.com> 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 fails for me as it looks like the NS for hhs.gov does not seem to resolve the hostname.
However dig +trace cms.hhs.gov resolves and so does dig +trace eclkc.ohs.acf.hhs.gov
However if I simply ask my local resolver to resolve cob.cms.hhs.gov, it works. Any thoughts on why this is the case?
Thanks,
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.
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?
On 15 Apr 2023, at 02:41, Doug Barton <dougb@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?
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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@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?
participants (6)
-
Bjørn Mork -
Doug Barton -
Mark Andrews -
Robert Story -
Samuel Jackson -
Stephane Bortzmeyer