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

[Brian Somers]

On Jul 8, 2020, at 12:03 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> 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. hostmaster at 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.
> 

The fem.gov folks made efforts to fix this.  We now have working TCP (yay!),
but they’ve managed to botch their NS RRset in two ways:

    $ dig +dnssec +nocrypt +noall +ans ns grantee.fema.gov
    grantee.fema.gov.       0       IN      NS      f5-gtm-external3.dc1.dhs.gov.
    grantee.fema.gov.       0       IN      RRSIG   NS 10 3 0 20200715213400 20200708213400 25856 grantee.fema.gov. [omitted]

The first is that their NS rdata is different from the parent’s and doesn’t resolve:

    $ dig +dnssec +nocrypt +noall +auth f5-gtm-external3.dc1.dhs.gov
    dhs.gov.                300     IN      SOA     a1-91.akam.net. dnssec1net.cbp.dhs.gov. 2008167381 10800 1080 604800 300
    dhs.gov.                300     IN      RRSIG   SOA 8 2 300 20200713113358 20200710103358 16593 dhs.gov. [omitted]
    sk5qori2d7g37j3v6pd02fk3lp89ahur.dhs.gov. 6 IN NSEC3 1 0 1 62B75FFDCA8A836A SKDI7NF2QL6G3KPQED8T4K4Q9LH57LUV A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM
    sk5qori2d7g37j3v6pd02fk3lp89ahur.dhs.gov. 6 IN RRSIG NSEC3 8 3 300 20200713113358 20200710103358 16593 dhs.gov. [omitted]
    u0kom144n419ejfd0h53mifi22u28odu.dhs.gov. 6 IN NSEC3 1 0 1 62B75FFDCA8A836A U2P01S5F48SUP0N3KUUIU64VVEQPEO2R A RRSIG
    u0kom144n419ejfd0h53mifi22u28odu.dhs.gov. 6 IN RRSIG NSEC3 8 3 300 20200713113358 20200710103358 16593 dhs.gov. [omitted]
    uqrh3j8sm5b3kh3mqk16quuo49t8bgki.dhs.gov. 6 IN NSEC3 1 0 1 62B75FFDCA8A836A UT42JCOMVUETD0M7J45IR1R57NK0N4CS A RRSIG
    uqrh3j8sm5b3kh3mqk16quuo49t8bgki.dhs.gov. 6 IN RRSIG NSEC3 8 3 300 20200713113358 20200710103358 16593 dhs.gov. [omitted]

The second is that they give us a zero-second TTL.  Conveniently that
prevents it from being cached and breaking the delegation!!  We’ve
reported this to them - we’ll see if it gets fixed soon.

—
Brian