Additional NS records in Authority section can cause validation failure

[mtgag]

Dear all,

when trying to validate records of gmx.net a SERVFAIL response appears. Do you know what the issue might be and if there is a fix for would it be possible to update the project providing it?

Please find a small programm demonstrating this issue.

import java.io.ByteArrayInputStream;

import org.jitsi.dnssec.validator.ValidatingResolver; import org.xbill.DNS.DClass; import org.xbill.DNS.Flags; import org.xbill.DNS.Message; import org.xbill.DNS.Name; import org.xbill.DNS.RRset; import org.xbill.DNS.Rcode; import org.xbill.DNS.Record; import org.xbill.DNS.Section; import org.xbill.DNS.SimpleResolver; import org.xbill.DNS.TXTRecord; import org.xbill.DNS.Type;

/**

• Simple dnssecjava example demonstrating SERVFAIL response for Name "gmx.net." (using our internal DNS server),
• while https://dnssec-analyzer.verisignlabs.com/gmx.net shows an "all-green" result using their default DNS server.
• However, depending on the DNS server, VeriSign's online DNSSEC analyzer shows different results:
• Okay: FreeDNS 45.33.97.5, UncensoredDNS 91.239.100.100, Hurricane Electric 74.82.42.42
• Warnings: Yandex.DNS 77.88.8.8, puntCAT 109.69.8.51, Cloudflare 1.1.1.1
• All other DNS servers listed at https://www.lifewire.com/free-and-public-dns-servers-2626062 produce errors. */ public class DnssecjavaDemo { public static void main(String[] args) throws Exception { ValidatingResolver vr = new ValidatingResolver(new SimpleResolver()); String ROOT = ". IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D"; vr.loadTrustAnchors(new ByteArrayInputStream(ROOT.getBytes("ASCII"))); Record qr = Record.newRecord(Name.fromConstantString("gmx.net."), Type.A, DClass.IN); Message response = vr.send(Message.newQuery(qr)); System.out.println("AD-Flag: " + response.getHeader().getFlag(Flags.AD)); System.out.println("RCode: " + Rcode.string(response.getRcode())); for (RRset set : response.getSectionRRsets(Section.ADDITIONAL)) { if (set.getName().equals(Name.root) && set.getType() == Type.TXT && set.getDClass() == ValidatingResolver.VALIDATION_REASON_QCLASS) { System.out.println("Reason: " + ((TXTRecord) set.first()).getStrings().get(0)); } } } }

Thank you very much.

Best Regards

Vangelis

[ibauersachs]

Testing all of the resolvers listed at Lifewire gives the following results. Since gmx.net is definitely a signed domain, I'd stay away from all resolvers that don't validate gmx.net (or any other domain) properly. Some of them imply in their name that they manipulate responses (AdGuard, Cleanbrowsing) while OpenDNS is well known for being bogus.

If your internal server is giving you a SERVFAIL, then it could be any of these reasons:

• running an outdated software
• using a forwarding server that manipulates DNS (e.g. OpenDNS, AdGuard, etc.)
• it's misconfigured

Using resolver: 8.8.8.8
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 9.9.9.9
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 208.67.222.222
---gmx.net.
Apr. 01, 2019 5:53:00 NACHM. org.jitsi.dnssec.validator.DnsSecVerifier verify
INFO: RRset failed to verify due to lack of signatures
AD-Flag: false
RCode:   SERVFAIL
Reason:  validate.bogus:dnskey.no_ds_match

Using resolver: 1.1.1.1
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 185.228.168.9
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 64.6.64.6
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 198.101.242.72
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 176.103.130.130
---gmx.net.
Apr. 01, 2019 5:53:02 NACHM. org.jitsi.dnssec.validator.DnsSecVerifier verify
INFO: RRset failed to verify due to lack of signatures
AD-Flag: false
RCode:   SERVFAIL
Reason:  validate.bogus.badkey:gmx.net.:failed.ds

Using resolver: 45.33.97.5
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 91.239.100.100
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 74.82.42.42
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 77.88.8.8
---gmx.net.
AD-Flag: true
RCode:   NOERROR

Using resolver: 109.69.8.51
---gmx.net.
AD-Flag: true
RCode:   NOERROR

[mtgag]

Hi,

thank you very much for your answer. We have analyzed this issue further and I would like to share the results with you. bind has the configuration option minimal-responses. This is configured with the values yes or no. If we configure bind with minimal-responses yes, then we haven't seen any issues. If we configure it with minimal-responses no, then the issue with the missing signature in the authority section appears. We would be grateful if you could consider this option in the project and provide an update for it. Is this possible?

Thank you very much.

Best Regards

Vangelis

[ibauersachs]

Can you please provide examples of a failing and a succeeding responses, e.g. a Wireshark capture or a BIND config to reproduce the queries? Failing this, I'll need at least trace-level log output from a query.

I'm wondering which additional records end up in the Authority section that cannot be validated. RFC 4035 mandates that RRsets in the Authority section need to have corresponding RRSIGs.

[mtgag]

Hello Ingo,

we have provided the wireshark traces per Email.

Best Regards

Vangelis

[ibauersachs]

To which address? I haven't received anything.

[ibauersachs]

Got them now, thanks! It'll take me a while to dive into this.

[ibauersachs]

@mtgag could you please check if #16 fixes this for you?

[ibauersachs]

v1.2.0 which contains this fix is now released to Maven Central.