Чтобы использовать стороннюю службу, я могу использовать их DNS-имя для разрешения их доменных имен. К сожалению, они используют некоторые плохие методы, такие как использование собственного придуманного TLD, который мы назовем tld в дальнейшем. Чтобы иметь возможность разрешать их доменные имена, я настроил переадресацию tld зона на моем локальном DNS-сервере с:
zone "tld." {
type forward;
forward only;
forwarders { x.x.x.x; };
};
куда x.x.x.x это их сервер имён. К сожалению sub.example.tld не разрешается из-за сбоя DNSSEC при поднятии DS выше в дереве, поскольку он пытается получить NS запись для tld из x.x.x.x которому отказано. Как (надеюсь) показано в следующем tcpdump с соответствующим выводом dig:
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
куда x.x.x.1 - это фактический правильный разрешенный IP для sub.example.tld. (Ошибочные контрольные суммы можно игнорировать, поскольку они являются ложноотрицательными)
Есть ли у меня другие варианты, кроме полного отключения DNSSEC на моем локальном DNS-сервере? Более того, уже подтверждено, что внешняя сторона не может изменить свою настройку DNS, не говоря уже о том, чтобы правильно включить DNSSEC.
Я не верю, что BIND умеет делать то, о чем вы просите.
Вы можете добавить якоря доверия, используя trusted-keys (который добавит / переопределит ключи вместо того, что будет использоваться в соответствии с DS записей, по сути), но нет никакого способа удалить доверие навсегда. Насколько я понимаю, рассматриваемая зона не подписана, поэтому добавление ключа для нее в качестве якоря доверия ничего не поможет.
В последних версиях есть способ временного добавления отрицательных якорей доверия с помощью rndc nta (и соответствующие nta-lifetime/nta-recheck settings), но это специально предназначено для временных обходных путей, и отрицательные якоря доверия истекают автоматически.