Hi Sandeep.
>From a quick look in Wireshark at what my own server (9.18.8) is doing,
this looks like Akamai not responding correctly to a BIND QNAME
minimisation query. Here's one response, from 95.101.36.192 for example, of
many similar ones showing an issue. The response code shouldn't be REFUSED:
Domain Name System (response)
Transaction ID: 0x87ea
Flags: 0x8005 Standard query response, Refused
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for
domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 0... .... = Recursion available: Server can't do
recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority
portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0101 = Reply code: Refused (5)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
_.stor.lb.akamai.net: type A, class IN
Name: _.stor.lb.akamai.net
[Name Length: 20]
[Label Count: 5]
Type: A (Host Address) (1)
Class: IN (0x0001)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (41)
UDP payload size: 4096
Higher bits in extended RCODE: 0x00
EDNS0 version: 0
Z: 0x8000
1... .... .... .... = DO bit: Accepts DNSSEC security RRs
.000 0000 0000 0000 = Reserved: 0x0000
Data length: 0
I haven't tested this on 9.18.10 or ..11 yet. But the behaviour of QM
hasn't changed.
I would advise you to run this on a non-production server, capture all
packets to disc and make some test queries to it until you see the issue,
to see what the server is actually doing.
I hope that helps, Greg
On Thu, 2 Feb 2023 at 23:43, Bhangui, Sandeep - BLS CTR via bind-users <
bind-users@lists.isc.org> wrote:
> Hi
>
> We are running ISC DNS Bind Version 9.18.10 ( will soon be moving to
> 9.18.11) on our Linux Servers.
>
> DNS resolution in general seems to work just fine as expected.
>
> It seems we have intermittent issues resolving "labor.upload.akamai.com"
> and then some scripts fail. It is clear that the failure of the script is
> due to DNS name lookup.
>
> Not sure if this is an issue that needs to be looked up at our end ( since
> DNS as such is working just fine for all the rest of the name resolution)
> or things are not configured properly at other end as far as how this DNS
> record is published and due to which I see the behavior of intermittent dns
> name lookup failure.
>
> Any pointers would be appreciated.
>
> Thanks
> Sandeep
>
> dig labor.upload.akamai.com
>
> ; <<>> DiG 9.18.10 <<>> labor.upload.akamai.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51211
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 17e14f79ba23179d0100000063dc4895fbcf47353a31763c (good)
> ;; QUESTION SECTION:
> ;labor.upload.akamai.com. IN A
>
> ;; Query time: 1203 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
> ;; WHEN: Thu Feb 02 18:34:45 EST 2023
> ;; MSG SIZE rcvd: 80
>
>
> But if I point to a public DNS server like VZ or google I seem to resolve
> it fine all the time.
>
> dig @198.6.1.1 labor.upload.akamai.com
>
> ; <<>> DiG 9.18.10 <<>> @198.6.1.1 labor.upload.akamai.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43891
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;labor.upload.akamai.com. IN A
>
> ;; ANSWER SECTION:
> labor.upload.akamai.com. 300 IN CNAME
> labor.c-ftp.upload.akamai.com.
> labor.c-ftp.upload.akamai.com. 900 IN CNAME
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net.
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.137
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.149
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.144
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.143
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.142
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.148
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.139
> r33674-33729.neards.1.cftp.e.stor.lb.akamai.net. 23 IN A 23.200.4.146
>
> ;; Query time: 202 msec
> ;; SERVER: 198.6.1.1#53(198.6.1.1) (UDP)
> ;; WHEN: Thu Feb 02 18:35:50 EST 2023
> ;; MSG SIZE rcvd: 267
> --
> 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
>
--
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
