AWS are returning NXDOMAIN instead of NOERROR for empty non terminals. Do you
have strict
qname minimisation turned on?
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1690
;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;us-east-1.aws.dckr.io. IN DS
;; AUTHORITY SECTION:
aws.dckr.io. 900 IN SOA ns-1870.awsdns-41.co.uk.
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 254 msec
;; SERVER: 2600:9000:5301:8d00::1#53(ns-397.awsdns-49.com) (UDP)
;; WHEN: Wed Oct 26 10:35:57 AEDT 2022
;; MSG SIZE rcvd: 137
> On 26 Oct 2022, at 10:23, PGNet Dev <pgnet....@gmail.com> wrote:
>
> i run bind 9.18.8
>
> i use root hints; forwarding is, by default, disabled in config
>
> with this config, i notice that although lookups for (e.g.) *.dock.io are
> available in public NS caches, e.g.
>
> dig A elb-default.us-east-1.aws.dckr.io @1.1.1.1
>
> ; <<>> DiG 9.18.8 <<>> A elb-default.us-east-1.aws.dckr.io
> @1.1.1.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43732
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0,
> ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;elb-default.us-east-1.aws.dckr.io. IN A
>
> ;; ANSWER SECTION:
> elb-default.us-east-1.aws.dckr.io. 11 IN CNAME
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com.
>
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 11
> IN A 52.3.144.121
>
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 11
> IN A 54.165.156.197
>
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 11
> IN A 44.196.175.70
>
> ;; Query time: 12 msec
> ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
> ;; WHEN: Tue Oct 25 18:59:05 EDT 2022
> ;; MSG SIZE rcvd: 195
>
> if I query at my local NS, i get NXDOMAIN response,
>
> dig A elb-default.us-east-1.aws.dckr.io @10.53.53.53
>
> ; <<>> DiG 9.18.8 <<>> A elb-default.us-east-1.aws.dckr.io
> @10.53.53.53
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23192
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0,
> ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: a1d6686d7992af170100000063586abe7c0a67d1ca4adf27
> (good)
> ;; QUESTION SECTION:
> ;elb-default.us-east-1.aws.dckr.io. IN A
>
> ;; Query time: 10 msec
> ;; SERVER: 10.53.53.53#53(10.53.53.53) (UDP)
> ;; WHEN: Tue Oct 25 19:01:18 EDT 2022
> ;; MSG SIZE rcvd: 90
>
>
> easy to workaround; if i simply forward for that zone,
>
> zone "dckr.io" IN {
> type forward; forward only; forwarders
> {1.1.1.1;2606:4700:4700::1111;1.0.0.1;2606:4700:4700::1001;};
> };
>
> & reload, then, local query works fine
>
> dig A elb-default.us-east-1.aws.dckr.io @10.53.53.53
>
> ; <<>> DiG 9.18.8 <<>> A elb-default.us-east-1.aws.dckr.io
> @10.53.53.53
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29726
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0,
> ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 7616190797188ad90100000063586afb58e880c12f1fb8ec
> (good)
> ;; QUESTION SECTION:
> ;elb-default.us-east-1.aws.dckr.io. IN A
>
> ;; ANSWER SECTION:
> elb-default.us-east-1.aws.dckr.io. 60 IN CNAME
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com.
>
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 60
> IN A 44.196.175.70
>
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 60
> IN A 52.3.144.121
>
> prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 60
> IN A 54.165.156.197
>
> ;; Query time: 175 msec
> ;; SERVER: 10.53.53.53#53(10.53.53.53) (UDP)
> ;; WHEN: Tue Oct 25 19:02:19 EDT 2022
> ;; MSG SIZE rcvd: 223
>
> the vast majority of queries to my local server are answered correctly.
>
> but, for three domains (so far ...) -- dock.io, netflix.com & moz.works --
> i'm having to implement these per-zone forwarding workarounds.
>
> is there an issue here that i can fix/cure in my not-forwarding-by-default
> config, so that these (and others out there too, i suppose ...) queries
> respond correctly ?
> if it's pebkac, dunno where to look, yet.
>
> or is it actually a problem on for these domains' DNS, and not much i can do
> about it ... other than workaround, or just default to forwarders ?
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
