0

To use a third party service, I can use their DNS name to resolve their domain names. Unfortunately they use some bad practices like using their own made up TLD, which we'll call tld hereafter. In order to be able to resolve their domain names I've set up a forwarding of the tld zone on my local DNS server with:

zone "tld." {
    type forward;
    forward only;
    forwarders { x.x.x.x; };
};

Where x.x.x.x is their nameserver. Unfortunately sub.example.tld does not get resolved due to DNSSEC failing on getting a DS higher up in the tree, as it tries to get a NS record for tld from x.x.x.x which is refused. As (hopefully) shown in the following tcpdump, with corresponding dig output:

dig @localhost sub.example.tld
22:23:58.104635 IP (tos 0x0, ttl 64, id 11345, offset 0, flags [none], proto UDP (17), length 77)
    egmaas.35308 > x.x.x.x.domain: [bad udp cksum 0x18b8 -> 0x708c!] 35515+% [1au] A? sub.example.tld. ar: . OPT UDPsize=4096 OK (49)
22:23:58.132413 IP (tos 0x0, ttl 62, id 62124, offset 0, flags [none], proto UDP (17), length 152)
    x.x.x.x.domain > egmaas.35308: [udp sum ok] 35515*- q: A? sub.example.tld. 1/2/1 sub.example.tld. [10h40m] A x.x.x.1 ns: example.tld. [10h40m] NS dkp-dns001.dmz.local., example.tld. [10h40m] NS dkp-dns002.dmz.local. ar: . OPT UDPsize=4096 OK (124)
22:23:58.132924 IP (tos 0x0, ttl 64, id 11351, offset 0, flags [none], proto UDP (17), length 71)
    egmaas.52511 > x.x.x.x.domain: [bad udp cksum 0x18b2 -> 0xe141!] 31932+% [1au] DS? example.tld. ar: . OPT UDPsize=4096 OK (43)
22:23:58.160128 IP (tos 0x0, ttl 62, id 62125, offset 0, flags [none], proto UDP (17), length 143)
    x.x.x.x.domain > egmaas.52511: [udp sum ok] 31932*- q: DS? example.tld. 0/1/1 ns: example.tld. [10h40m] SOA dkp-dns001.dmz.local. admin.tld.org. 2015062301 10800 3600 604800 38400 ar: . OPT UDPsize=4096 OK (115)
22:23:58.174284 IP (tos 0x0, ttl 64, id 11356, offset 0, flags [none], proto UDP (17), length 63)
    egmaas.57612 > x.x.x.x.domain: [bad udp cksum 0x18aa -> 0x3f69!] 19858+% [1au] NS? tld. ar: . OPT UDPsize=4096 OK (35)
22:23:58.201136 IP (tos 0x0, ttl 62, id 62126, offset 0, flags [none], proto UDP (17), length 63)
    x.x.x.x.domain > egmaas.57612: [udp sum ok] 19858 Refused- q: NS? tld. 0/0/1 ar: . OPT UDPsize=4096 OK (35)

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @localhost sub.example.tld
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41059
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sub.example.tld.       IN  A

;; Query time: 97 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Oct 24 22:23:58 CEST 2016
;; MSG SIZE  rcvd: 49

Where x.x.x.1 is the actual correct resolved IP for sub.example.tld. (The bad checksums can be ignored as they are a false negatives)

Do I have any options other than disabling DNSSEC completely on my local DNS server? Furthermore, it is already verified that the external party is not able to change their DNS setup, let alone actually incorporate DNSSEC correctly.

hbogert
  • 411
  • 1
  • 5
  • 18

1 Answers1

2

I don't believe BIND has a good way of doing what you ask for.

You can add trust anchors using trusted-keys (which would add/override keys over what would be used according to DS records, essentially) but there is no way of removing trust in a permanent way. From my understanding the zone in question is not signed, so adding a key for it as a trust anchor will not help anything.

The latest versions do have a way of temporarily adding negative trust anchors with rndc nta (and the corresponding nta-lifetime/nta-recheck settings), but this is specifically intended for temporary workarounds and negative trust anchors expire automatically.

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • For reference, possibly relevant: unbound has the [`domain-insecure`](https://www.unbound.net/documentation/unbound.conf.html) setting, powerdns-recursor has the [`addNTA`](https://doc.powerdns.com/md/recursor/dnssec/#negative-trust-anchors) function in `lua-config-file`, etc. – Håkan Lindqvist Oct 24 '16 at 22:38
  • Ok, then can we do something dirty, like shadowing the `tld.` by defining this in my own DNS and add a trust-key for that? Still, subdomains, e.g., example.com, should be forwarded to *their* nameserver. Also I'd need to handle the `NS? tld.` request which is now being refused by their nameserver, breaking the validation before actual crypto validation is actually being done. – hbogert Oct 26 '16 at 08:33
  • Followup, how did things get forwarded to subdomains of `.com` at the time that `.com` was not signed, without having the issues I encountered as described in the Question? In that case, if an example.com was non-DNSSEC, it would've been completely the same thing like having `example.tld` right? – hbogert Oct 28 '16 at 09:27
  • @hbogert When you encounter a delegation with proof of non-existance for `DS` records you know that the delegated zone is not supposed to be signed (*insecure*, if you will) and stop validating at that point. This is what eg a signed `com` but unsigned `serverfault.com` is (or a signed root but unsigned com), but that is very different from overlaying a made up zone over the real DNS tree, with no delegation in place at all. – Håkan Lindqvist Oct 28 '16 at 16:14
  • @hbogert Ie, what you would need for validation to work is queries to the authoritative servers for the parent (root zone) to be answered with delegation information for your tld along with proof that it's not supposed to be signed, what you get is proof that the tld doesn't exist (so far). – Håkan Lindqvist Oct 28 '16 at 16:47
  • @hbogert " how did things get forwarded to subdomains of .com at the time that .com was not signed," when DNSSEC started to exist, and people wanted to use it when parent zones (TLDs, the root) were not signed yet, there was the DLV - DNSSEC lookaside validation which is both a DNS record type and a specific zone, at that time maintained by ISC. So it was possible to basically use a "second" tree to validate DNSSEC records. All of this is now obsolete and shutdown because the root is signed, as are many (but not all) TLDs. – Patrick Mevzek Jul 11 '19 at 05:09