Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Kipper, Brian (CTR) via dns-operations]

--- Begin Message ---
Hello Everyone,
  I am the DNS SME for DHS. I was made aware of this thread, and I 
wanted to post a note that we have resolved the issue and things should be 
responding correctly. In the future If you see any issues with other sites 
under the dhs.gov umbrella, please feel free to reach out and let us know.


Thanks,


Brian Kipper
OneNET Engineering Team
Department of Homeland Security
Office: 202-447-5037
Cell: 202-579-8370  *Please note Corrected Cell #
Email: 
brian.l.kip...@associates.dhs.gov
[ccent_network_sm][ccna_routerswitching_sm][CCNA_security_sm][DHS OneNet 
logo_final resized 2]

--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Viktor Dukhovni]

On Wed, Jul 08, 2020 at 05:07:43PM -0700, Brian Somers wrote:

> Interesting.  I just see:
> 
> # dig +cd +norecurse +tries=1 +bufsize=2000 +dnssec dnskey 
> grantee.fema.gov @216.81.81.101
> 
> ; <<>> DiG 9.16.4 <<>> +cd +norecurse +tries +bufsize +dnssec dnskey 
> grantee.fema.gov @216.81.81.101
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> Never a response when I give it a big enough bufsize…
> I wonder what unbound is doing that dig isn’t.
> 
> Of course our resolvers only ask for bufsize=1410, get a
> TC, ask over TCP and get a response with just the SOA,
> which isn’t even a valid denial :(

There is likely a network path between your machine and the
authoritative servers where IP fragments are dropped, and
reassembly of the full UDP datagram fails.

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Brian Somers]

On Jul 8, 2020, at 12:22 PM, Stephane Bortzmeyer  wrote:
> 
>> 
>> No. My BIND and Unbound personal resolvers (which do not have a NTA)
>> get a reply and set AD.
> 
> There are probably several different instances for each authoritative
> server of grantee.fema.gov, and they behave differently. Here, seen by
> the RIPE Atlas probes, you can se that some probes can get a DNSKEY
> (when using the DO bit) and some cannot (timeout):

Yes, I believe this is true.

If I query from San Jose or Vancouver I get the timeout.  But querying from a
machine in the UK provides an answer.

—
Brian
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Brian Somers]

On Jul 8, 2020, at 12:31 PM, Viktor Dukhovni  wrote:
> 
> With even more verbose debugging, unbound-host reports a DNSKEY response
> size of 1842 bytes.

Interesting.  I just see:

# dig +cd +norecurse +tries=1 +bufsize=2000 +dnssec dnskey grantee.fema.gov 
@216.81.81.101

; <<>> DiG 9.16.4 <<>> +cd +norecurse +tries +bufsize +dnssec dnskey 
grantee.fema.gov @216.81.81.101
;; global options: +cmd
;; connection timed out; no servers could be reached

Never a response when I give it a big enough bufsize…
I wonder what unbound is doing that dig isn’t.

Of course our resolvers only ask for bufsize=1410, get a
TC, ask over TCP and get a response with just the SOA,
which isn’t even a valid denial :(

—
Brian
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Viktor Dukhovni]

On Wed, Jul 08, 2020 at 03:03:57PM -0400, Viktor Dukhovni wrote:

> > However, grantee.fema.gov is horribly broken:
> > • Querying the authority for the DNSKEY without the DO bit works 
> > (getting the DNSKEY with no signatures)
> > • Querying the authority for the DNSKEY with the DO bit fails (times 
> > out or sets TC)
> > • Querying the authority for the DNSKEY over TCP gets NODATA with an 
> > SOA but no other  AUTHORITY RRs, regardless of the DO bit
> 
> But for me, the DNSKEY and A record queries are working presently:

That is, working with direct queries to the authorities, bypassing my
local unbound resolver, or with unbound-host (below).  The unbound
resolver fails, it is configured with a modest UDP buffer size.

...
[1594236070] libunbound[1398600:0] info: resolving fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: resolving (init part 2):  
fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: resolving (init part 3):  
fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: processQueryTargets: fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] info: sending query: fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] debug: sending to target:  
23.211.61.66#53
[1594236070] libunbound[1398600:0] debug: iterator[module 2] operate: 
extstate:module_wait_reply event:module_event_reply
[1594236070] libunbound[1398600:0] info: iterator operate: query fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] info: response for fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: reply from  
23.211.61.66#53
[1594236070] libunbound[1398600:0] info: query response was ANSWER
[1594236070] libunbound[1398600:0] info: finishing processing for fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] debug: validator[module 1] operate: 
extstate:module_wait_module event:module_event_moddone
[1594236070] libunbound[1398600:0] info: validator operate: query fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] debug: subnet[module 0] operate: 
extstate:module_wait_module event:module_event_moddone
[1594236070] libunbound[1398600:0] info: subnet operate: query fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] info: validated DNSKEY fema.gov. DNSKEY 
IN
[1594236070] libunbound[1398600:0] debug: validator[module 1] operate: 
extstate:module_wait_subquery event:module_event_pass
[1594236070] libunbound[1398600:0] info: validator operate: query 
grantee.fema.gov. A IN
[1594236070] libunbound[1398600:0] info: validated DS grantee.fema.gov. DS 
IN
[1594236070] libunbound[1398600:0] debug: subnet[module 0] operate: 
extstate:module_state_initial event:module_event_pass
[1594236070] libunbound[1398600:0] info: subnet operate: query 
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] debug: validator[module 1] operate: 
extstate:module_state_initial event:module_event_pass
[1594236070] libunbound[1398600:0] info: validator operate: query 
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] debug: iterator[module 2] operate: 
extstate:module_state_initial event:module_event_pass
[1594236070] libunbound[1398600:0] info: resolving grantee.fema.gov. DNSKEY 
IN
[1594236070] libunbound[1398600:0] info: resolving (init part 2):  
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: resolving (init part 3):  
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: processQueryTargets: 
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: sending query: grantee.fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] debug: sending to target: 
 216.81.81.101#53
[1594236070] libunbound[1398600:0] debug: iterator[module 2] operate: 
extstate:module_wait_reply event:module_event_reply
[1594236070] libunbound[1398600:0] info: iterator operate: query 
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: response for grantee.fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] info: reply from  
216.81.81.101#53
[1594236070] libunbound[1398600:0] info: query response was ANSWER
[1594236070] libunbound[1398600:0] info: finishing processing for 
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] debug: validator[module 1] operate: 
extstate:module_wait_module event:module_event_moddone
[1594236070] libunbound[1398600:0] info: validator operate: query 
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] debug: subnet[module 0] operate: 
extstate:module_wait_module event:module_event_moddone
[1594236070] libunbound[1398600:0] info: subnet operate: query 
grantee.fema.gov. DNSKEY IN
[1594236070] libunbound[1398600:0] info: validated DNSKEY grantee.fema.gov. 
DNSKEY IN
[1594236070] libunbound[1398600:0] debug: validator[module 1] operate: 
extstate:module_wait_subquery event:module_event_pass

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Stephane Bortzmeyer]

On Wed, Jul 08, 2020 at 09:15:02PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 57 lines which said:

> No. My BIND and Unbound personal resolvers (which do not have a NTA)
> get a reply and set AD.

There are probably several different instances for each authoritative
server of grantee.fema.gov, and they behave differently. Here, seen by
the RIPE Atlas probes, you can se that some probes can get a DNSKEY
(when using the DO bit) and some cannot (timeout):

% blaeu-resolve -4 -r 100 --nameserver ns-dc2gtm1.dhs.gov. --type DNSKEY 
--dnssec grantee.fema.gov.
Nameserver ns-dc2gtm1.dhs.gov.
[TIMEOUT] : 37 occurrences
[256 3 10 aweaabvxfgryn7jl7igk3k7zpjbmvovaepmsbnn/lsugzqz6pjgz6y3/7geibgg3 
ubrwa 256 3 10 aweaachfofxdoii8+/ljej5ctuursgky 
h3ydxjf6t/wurehzelr77yi0i8tmcpyibmo6a 257 3 10 
aweaabronsypatfnhwvyn0ipda3l6hp5zwzc2i2mlxts85hvsdnhpghirwzjaio mob3e 257 3 10 
aweaadfgkwupgfkp7qayvzzcrs5jza2d jlkzqkwrg90wxdvo5anbrxncoiw3kzv0 ugj+k] : 61 
occurrences
[ERROR: SERVFAIL] : 2 occurrences
Test #26219900 done at 2020-07-08T19:19:20Z

Probably because they do to different instances of ns-dc2gtm1.dhs.gov.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Stephane Bortzmeyer]

On Wed, Jul 08, 2020 at 11:20:27AM -0700,
 Brian Somers  wrote 
 a message of 38 lines which said:

> I can only suspect that all 3 of these resolvers have an NTA for
> this domain!

No. My BIND and Unbound personal resolvers (which do not have a NTA)
get a reply and set AD. The truth is elsewhere.

% dig A grantee.fema.gov.

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> A grantee.fema.gov.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62146
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL:
;; 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;grantee.fema.gov.  IN A

;; ANSWER SECTION:
grantee.fema.gov.   30 IN A 173.255.49.196
grantee.fema.gov.   30 IN RRSIG A 10 3 30 (
20200715002926 20200708002926
38990 grantee.fema.gov.

RolWLU7SxjgBJGOIXELMDVXK641r1oI3p7icXEJLjWM+

4GLdidyuwIqnSr5GyzG5zBSW4g+J9ZZWvz18asrCJcqp


+t+DtARbXoumyyTWMTKRh1TtqkQre3ncfM3vQAEOtRbp


Tjq3jmBdrwv+VQElWRYQ0H2Oy3NhiRQ6EJXNvOs=


)


grantee.fema.gov.


30


IN


RRSIG


A


10


3


30


(


20200712161915


20200705161915


25856


grantee.fema.gov.



NIKjzoiiFtvZ6KhH+eOF+ikxSU9iomF7aizRmN15Z23x



fVQkxB8sKRYtFdfWzlY5oBl0V/LVAXJI+TeuN4ovv+cT




7EZGYAC5q6y6I2CmcTtoDgmFHbSS90bLUC5ndYornCLD
  

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Marek Vavruša]

I can confirm for 1.1.1.1. The main problem is that DNSKEY with DO bit
doesn't fit in UDP response without fragmentation and TCP retry
returns NODATA, so it's not retrievable unless you set the bufsize to
at least 1853 bytes (DO bit bumps the response size). There's a
workaround for that so at least A record resolves for the time being.
We've reached to FEMA, so hopefully it'll get fixed soon.

Marek



On Wed, 8 Jul 2020 at 11:41, Brian Somers  wrote:
>
> I thought this was worth a question here as I’m completely confused about how
> this domain functions.
>
> As a preamble, the fema.gov authorities have a grantee.fema.gov/DS RRset
> and respond correctly:
> # dig +short ns fema.gov
> a1-91.akam.net.
> a7-64.akam.net.
> a8-65.akam.net.
> a9-66.akam.net.
> a16-67.akam.net.
> a22-66.akam.net.
>
> # dig +noall +auth +dnssec +nocrypt grantee.fema.gov @a1-91.akam.net
> grantee.fema.gov.   86400   IN  DS  1164 10 1 [omitted]
> grantee.fema.gov.   86400   IN  RRSIG   DS 8 3 86400 
> 20200711020644 20200708010644 27168 fema.gov. [omitted]
> grantee.fema.gov.   300 IN  NS  ns-dc2gtm2.dhs.gov.
> grantee.fema.gov.   300 IN  NS  ns-dc1gtm1.dhs.gov.
> grantee.fema.gov.   300 IN  NS  ns-dc2gtm1.dhs.gov.
> grantee.fema.gov.   300 IN  NS  ns-dc1gtm2.dhs.gov.
>
> However, grantee.fema.gov is horribly broken:
> • Querying the authority for the DNSKEY without the DO bit works (getting 
> the DNSKEY with no signatures)
> • Querying the authority for the DNSKEY with the DO bit fails (times out 
> or sets TC)
> • Querying the authority for the DNSKEY over TCP gets NODATA with an SOA 
> but no other  AUTHORITY RRs, regardless of the DO bit
>
> The bit that confuses me however:
> • Querying 1.1.1.1, 8.8.8.8 and 9.9.9.9 for grantee.fema.gov/A works.
>   8.8.8.8 even sets the AD bit.
> • Querying 8.8.8.8 and 9.9.9.9 for grantee.fema.gov/DNSKEY
>   * works without the DO bit
>   * fails with the DO bit (NODATA and no auth RRs or else a TIMEOUT)
> • Querying 1.1.1.1 for grantee.fema.gov/DNSKEY
>   * gets SERVFAIL, regardless of the DO bit.
>
> I can only suspect that all 3 of these resolvers have an NTA for this domain!
> Other resolvers such as 64.6.64.6 (and 208.67.222.2) correctly SERVFAIL
> the grantee.fema.gov/A query while 156.154.70.5 responds and includes the
> AD bit.
>
> Can anybody confirm/deny?
>
> —
> Brian
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Viktor Dukhovni]

On Wed, Jul 08, 2020 at 11:20:27AM -0700, Brian Somers wrote:

> # dig +noall +auth +dnssec +nocrypt grantee.fema.gov @a1-91.akam.net
> grantee.fema.gov.   86400   IN  DS  1164 10 1 [omitted]
> grantee.fema.gov.   86400   IN  RRSIG   DS 8 3 86400 
> 20200711020644 20200708010644 27168 fema.gov. [omitted]
> grantee.fema.gov.   300 IN  NS  ns-dc2gtm2.dhs.gov.
> grantee.fema.gov.   300 IN  NS  ns-dc1gtm1.dhs.gov.
> grantee.fema.gov.   300 IN  NS  ns-dc2gtm1.dhs.gov.
> grantee.fema.gov.   300 IN  NS  ns-dc1gtm2.dhs.gov.

Note the SOA record for the child zone:

fema.gov. IN SOA F5-GTM-External4.dc1.dhs.gov. 
hostmas...@f5-gtm-external4.dc1.dhs.gov. 2020063002 10800 3600 604800 60

It is probably fair to guess that DNS for this domain is delegated to an
F5 load-balancer.  These sorts of devices tend to have minimal
seat-of-the-pants DNS implementations, and correct support for DNSSEC
among these is not the norm.

Querying the authoritative server for the SOA record (with the DO bit
set) returns an SOA with no RRSIGs.  Querying for the NS RRset returns
the same unsigned SOA with no NS records!

> However, grantee.fema.gov is horribly broken:
> • Querying the authority for the DNSKEY without the DO bit works (getting 
> the DNSKEY with no signatures)
> • Querying the authority for the DNSKEY with the DO bit fails (times out 
> or sets TC)
> • Querying the authority for the DNSKEY over TCP gets NODATA with an SOA 
> but no other  AUTHORITY RRs, regardless of the DO bit

But for me, the DNSKEY and A record queries are working presently:

grantee.fema.gov. IN DNSKEY 256 3 10 
AwEAAchfOfxDOIi8+/ljEj5ctUursgKyh3yDxjF6T/WUrEHZeLr77yi0I8tmCpYIbMO6Aul2+7XtuLMsdBpnQ7ThhVLqIuXWQaAkCPIuEFSqT4pNqikOpGh9ecmtSCAnOii/uiZv5TEM5jF9s5XxPAkYhN8lo/O0M2BmGhVyWxuhLs5x
grantee.fema.gov. IN DNSKEY 256 3 10 
AwEAAbVXfgRYn7jl7igK3k7ZpJBMvoVAepmSBnN/LSUGZQZ6pjgz6y3/7GEiBGg3UbRWAF2ygs5gw1x+QXun1C2yDlrmQ37OGcJXoj/TDHZHFyl6CZ31UwIMNZjSs/zdJsBGLA2CoDGG4zO0U1CHuYUGBr0KLWfb495D3LK3zzPpDtyv
grantee.fema.gov. IN DNSKEY 257 3 10 
AwEAAdFgKwUpGFKp7qAyVzzcRS5jZA2dJLkZQKWRG90wXdVO5anbrXNcOIw3Kzv0ugJ+KoHMV0hAZx0ZFpE1lJFMC60iJkeS7qAGTT+Vzfk4VWZFWcuNf0SJgbla8W5ei/+sjxnYR2yY1IJ3+t7FE7W+uYh2tj0OxuDA9xYAKc3K6ZDFWSIw9k6f/WDQvii2I0NE6Yo9ZxV6etvVAuy2nvEt9rLCIwI2PGyMLYzQxbH9AaTxDQ6u8lHBN0PB8GuDr5BhZK4V0e5YRbhb8tCv7FDzXA0k/sTeHUtyIvT0PKLo/nHZ+8NeA9jVWAeJLPl/tgkgAxo/qUvLYpjKs5DT8g8HSX0=
grantee.fema.gov. IN DNSKEY 257 3 10 
AwEAAbronSyPATfnHwvyn0ipda3l6HP5ZWZc2i2mlXtS85HvsdNHPghIRwZJaiOYmob3ED6ZoobJuREZje/FkXpRnoAfXi4wx70GEZRokUt8fcsjuPorbnDVrZjmaYqoERMv6M1XoT8JirIbvkfUp/kjia88xJ23gJjqT3BYkNHJr5y/kVhdUenpouuCfg3Ln5M5t08dYYUZeKGJ4LKw6SyJFBVBaOesn1N2p4AGRg4nQDzVC4p8YslFaZt1RSdLh9xT1FNNKx69vH631VgzZW3eaG6+KmXTNNhxOePuX1te5he1yjW0rXz4OjlFOP0WkBeBj0egRvce6MltIw8EvIyX2Jk=
grantee.fema.gov. IN RRSIG DNSKEY 10 3 86400 20200712003126 20200705003126 
38990 grantee.fema.gov. 
X35dRWfqrnQn9CdTFG+qhSjPkKkPDIigiqIWxdt97wL7f/aJK75iahgvQrYyhx4FtPpF+ww21jFRqY5V1W7WNoFjND6YpXWtSZ/TDr3tEGqCX/cFpSN5nkTfs5N3x7d1VmhcRvH6Z5H1FizRhrGj3/E09UI/m4n35hIdoDKL2+M=
grantee.fema.gov. IN RRSIG DNSKEY 10 3 86400 20200712003126 20200705003126 
25856 grantee.fema.gov. 
LkmCeBgiMoHb6/BJuAIm61wu1jlm6XLq9e4hAFd95bY6o1iaE10NP80913NZTfz2FLFhJUnHIQ4w2aD2keyE7JHKvEWtxPV4h3XXVhBNd6T1c3dWcWF38GAEluswp8jR62mnusOTxcyhhggJBfpFtcG2Lt8V3ejMFSBxpYqS4eU=
grantee.fema.gov. IN RRSIG DNSKEY 10 3 86400 20200712003126 20200705003126 
1164 grantee.fema.gov. 
UyyiOzvwUVQtov0HiKOLmZG56dLESMjysDrvG/SIyz5rr7uGPTwXXW8gUa+UTxXh3KfRsssC7AIqISH3wLLy3dGEjri+AJLZOZRr5Dc6q19QEOsQGMk0T8pxjwZipeLomYSLiVVAN27PBjO8svJccKpjPeGfUxIr5Jqr4wo369WGcdO0Ev9k5fkhPCeRk84RuxGymCEqpa4K7jANmxiKlclRMYZcqNpuso/Dl5Prjz9BjT3GjvV4REpw6SetNsEC4nMhsnpgCpkIN+jd/g+yGbnZS42ghc+rTU+Dgk7cWOsFhLzB+TEHkRqDx84fPTW2yXyvLE99qSe0t68XnGANkQ==
grantee.fema.gov. IN RRSIG DNSKEY 10 3 86400 20200712003126 20200705003126 
48924 grantee.fema.gov. 
N/3HIFIJMN6O7+nk0z7sUPU/2XSIwcjM/6USG20OXP24wu587pT1wv/lytDFB98445/xHPr9K39kI0yb0sbx61ISWtwGJQ3jirUuIO4mBwhZZq6rXYfJmTThdEBJnsJUP4+0qzNCczc5h6x8cfyQoQnQ3rkzQj3UbDX55pNSaDCb2J5h8sO432iyfEH6iOuyDWeH5BXphioYeXEeNRh+qhtMYnwSSLkLwrr+p3FYDLjZ+SJR7G1IVJVkoj9Nr9cJqtBQlg4UR2wF83EXY68G4EAS3PPwUQezf0GLEDijjBfCGuCafP8c7eC/K/aE5yDLUcFevlgG6RXoKbdl6remXQ==

grantee.fema.gov. IN A 173.255.49.196
grantee.fema.gov. IN RRSIG A 10 3 30 20200715002505 20200708002505 38990 
grantee.fema.gov. 
hd7/3YGekRnmzahjGDpcWYj9GaSQWghUJZiHXeCTmXxVTQddHAd1CRPD+kh8CHHkcCXfTm7AyMjrnW8X2qUtgFe+ZMDVbGsEkAI50sxIMI+Zu2aLiClOtQFdqdCkw6Zd0KCvmemN8etr2NYxKO7KV8+VbrVfWS4mR3hU0qZo2bA=
grantee.fema.gov. IN RRSIG A 10 3 30 20200712162346 20200705162346 25856 
grantee.fema.gov. 
YYrWcxlsNjFYSJLUMuUce/W+aySCMXYot2UkHtG+YZ6Mjs6L5pdb2m/By3NJDfHt6IZDl2xS/4eo6RmtuvxPHSfNLedP/HdpBoCsDIHiYY7ni6lt1NDO+EWKaD4DjrFFat54m6mblxT0SzGrqsdFUblaR+DgMCuAD6v1joaBfX4=

> The bit that confuses me however:
> • Querying 

[dns-operations] Dealing with the bizarre - grantee.fema.gov

[Brian Somers]

I thought this was worth a question here as I’m completely confused about how
this domain functions.

As a preamble, the fema.gov authorities have a grantee.fema.gov/DS RRset
and respond correctly:
# dig +short ns fema.gov
a1-91.akam.net.
a7-64.akam.net.
a8-65.akam.net.
a9-66.akam.net.
a16-67.akam.net.
a22-66.akam.net.

# dig +noall +auth +dnssec +nocrypt grantee.fema.gov @a1-91.akam.net
grantee.fema.gov.   86400   IN  DS  1164 10 1 [omitted]
grantee.fema.gov.   86400   IN  RRSIG   DS 8 3 86400 20200711020644 
20200708010644 27168 fema.gov. [omitted]
grantee.fema.gov.   300 IN  NS  ns-dc2gtm2.dhs.gov.
grantee.fema.gov.   300 IN  NS  ns-dc1gtm1.dhs.gov.
grantee.fema.gov.   300 IN  NS  ns-dc2gtm1.dhs.gov.
grantee.fema.gov.   300 IN  NS  ns-dc1gtm2.dhs.gov.

However, grantee.fema.gov is horribly broken:
• Querying the authority for the DNSKEY without the DO bit works (getting 
the DNSKEY with no signatures)
• Querying the authority for the DNSKEY with the DO bit fails (times out or 
sets TC)
• Querying the authority for the DNSKEY over TCP gets NODATA with an SOA 
but no other  AUTHORITY RRs, regardless of the DO bit

The bit that confuses me however:
• Querying 1.1.1.1, 8.8.8.8 and 9.9.9.9 for grantee.fema.gov/A works.
  8.8.8.8 even sets the AD bit.
• Querying 8.8.8.8 and 9.9.9.9 for grantee.fema.gov/DNSKEY
  * works without the DO bit
  * fails with the DO bit (NODATA and no auth RRs or else a TIMEOUT)
• Querying 1.1.1.1 for grantee.fema.gov/DNSKEY
  * gets SERVFAIL, regardless of the DO bit.

I can only suspect that all 3 of these resolvers have an NTA for this domain!
Other resolvers such as 64.6.64.6 (and 208.67.222.2) correctly SERVFAIL
the grantee.fema.gov/A query while 156.154.70.5 responds and includes the
AD bit.

Can anybody confirm/deny?

—
Brian
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations