powered by Jive Software

Smack 4.3.0 DNSSEC is not working at root-zone DS record validation


#21

After more testings and debugging, I believe now I understand the whole problem:
To avoid break point causing problem, I now include log messages for tracing.

  1. With each of the enum constructor, I add the following code:
        private Selector(byte byteValue)
        {
            this.byteValue = byteValue;
            SELECTOR_LUT.put(byteValue, this);
            LOGGER.warning("## Selector constructor SELECTOR_LUT status: " + SELECTOR_LUT.get(byteValue));
        }
  1. and also within TLSA…
    TLSA(byte certUsageByte, byte selectorByte, byte matchingTypeByte, byte[] certificateAssociation)
    {
        LOGGER.warning("LUTs array size status before init: " + CERT_USAGE_LUT.size());
        if (CERT_USAGE_LUT.isEmpty()) {
            CertUsage.valueOf("caConstraint");
            Selector.values();
            MatchingType.values();
            LOGGER.warning("LUTs array size status after init: " + CERT_USAGE_LUT.size());
        }

        this.certUsageByte = certUsageByte;
...
}

And these are the log messages on execution:

08-28 10:51:43.171 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() LUTs array size status before init: 0
08-28 10:51:43.180 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## CertUsage constructor CERT_USAGE_LUT status: caConstraint
08-28 10:51:43.186 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## CertUsage constructor CERT_USAGE_LUT status: serviceCertificateConstraint
08-28 10:51:43.192 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## CertUsage constructor CERT_USAGE_LUT status: trustAnchorAssertion
08-28 10:51:43.198 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## CertUsage constructor CERT_USAGE_LUT status: domainIssuedCertificate
08-28 10:51:43.204 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## Selector constructor SELECTOR_LUT status: fullCertificate
08-28 10:51:43.209 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## Selector constructor SELECTOR_LUT status: subjectPublicKeyInfo
08-28 10:51:43.215 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## MatchingType constructor MATCHING_TYPE_LUT status: noHash
08-28 10:51:43.219 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## MatchingType constructor MATCHING_TYPE_LUT status: sha256
08-28 10:51:43.223 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() ## MatchingType constructor MATCHING_TYPE_LUT status: sha512
08-28 10:51:43.228 22677-23499/org.atalk.android W/aTalk: [3875] org.minidns.record.TLSA.<init>() LUTs array size status after init: 4
  1. In conclusion:
    3a. The private construction for each enum class is not being executed, until one of its element is being accessed.
    3b. The CERT_USAGE_LUT.size() and CERT_USAGE_LUT.isempty() do not trigger the execution of the enum constructor

Here is my latest patch:
minidns-core-0.3.2.patch (3.8 KB)


#22

Got it now, the static init block fo the LUTs where missing. I am working on a fix.


#23

Pushed

and

will probably be included in next MiniDNS release and Smack 4.3.1.


#24

Can we just ignore the exception as does not abort the app?

The exception message just appears next to the ‘this’ in the Debug window. It seems that android/java performs a toString() on entry to TLSA. Since certificateAssociation is null at this point, hence the exception message. My patch check for (certificateAssociation != null) before append the parameter. This fixed and the exception message does not appear any more.


#25

The exception should not occur with the commits from above.

It is an sympton of the LUTs not being initialized when the TLSA constructor is invoked, which, in turn, causes some fields being set to null, ultimately resulting in the log message

which should not be seen, at least for byte values < 4. You can ignore it, as in it is thrown within a debug thread, but of course, the bug still exists (if you don’t run a version which includes the fix from above).


#26

Fix tested working. Thanks

Just realize that the reported Exception message is actually info shown by the android debugger while trying to show the TLSA content to the user, it has nothing to do the application execution. So it can be safely ignored.