<div dir="ltr">Hi Sandeep.<div>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:</div><div><br></div><div>Domain Name System (response)<br> Transaction ID: 0x87ea<br> Flags: 0x8005 Standard query response, Refused<br> 1... .... .... .... = Response: Message is a response<br> .000 0... .... .... = Opcode: Standard query (0)<br> .... .0.. .... .... = Authoritative: Server is not an authority for domain<br> .... ..0. .... .... = Truncated: Message is not truncated<br> .... ...0 .... .... = Recursion desired: Don't do query recursively<br> .... .... 0... .... = Recursion available: Server can't do recursive queries<br> .... .... .0.. .... = Z: reserved (0)<br> .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server<br> .... .... ...0 .... = Non-authenticated data: Unacceptable<br> .... .... .... 0101 = Reply code: Refused (5)<br> Questions: 1<br> Answer RRs: 0<br> Authority RRs: 0<br> Additional RRs: 1<br> Queries<br> _.<a href="http://stor.lb.akamai.net">stor.lb.akamai.net</a>: type A, class IN<br> Name: _.<a href="http://stor.lb.akamai.net">stor.lb.akamai.net</a><br> [Name Length: 20]<br> [Label Count: 5]<br> Type: A (Host Address) (1)<br> Class: IN (0x0001)<br> Additional records<br> <Root>: type OPT<br> Name: <Root><br> Type: OPT (41)<br> UDP payload size: 4096<br> Higher bits in extended RCODE: 0x00<br> EDNS0 version: 0<br> Z: 0x8000<br> 1... .... .... .... = DO bit: Accepts DNSSEC security RRs<br> .000 0000 0000 0000 = Reserved: 0x0000<br> Data length: 0<br></div><div><br></div><div>I haven't tested this on 9.18.10 or ..11 yet. But the behaviour of QM hasn't changed.</div><div><br></div><div>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.</div><div><br></div><div>I hope that helps, Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 2 Feb 2023 at 23:43, Bhangui, Sandeep - BLS CTR via bind-users <<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
We are running ISC DNS Bind Version 9.18.10 ( will soon be moving to 9.18.11) on our Linux Servers.<br>
<br>
DNS resolution in general seems to work just fine as expected.<br>
<br>
It seems we have intermittent issues resolving "<a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a>" and then some scripts fail. It is clear that the failure of the script is due to DNS name lookup.<br>
<br>
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.<br>
<br>
Any pointers would be appreciated.<br>
<br>
Thanks<br>
Sandeep<br>
<br>
dig <a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a><br>
<br>
; <<>> DiG 9.18.10 <<>> <a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a><br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51211<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 1232<br>
; COOKIE: 17e14f79ba23179d0100000063dc4895fbcf47353a31763c (good)<br>
;; QUESTION SECTION:<br>
;<a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a>. IN A<br>
<br>
;; Query time: 1203 msec<br>
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)<br>
;; WHEN: Thu Feb 02 18:34:45 EST 2023<br>
;; MSG SIZE rcvd: 80<br>
<br>
<br>
But if I point to a public DNS server like VZ or google I seem to resolve it fine all the time.<br>
<br>
dig @<a href="http://198.6.1.1" rel="noreferrer" target="_blank">198.6.1.1</a> <a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a><br>
<br>
; <<>> DiG 9.18.10 <<>> @<a href="http://198.6.1.1" rel="noreferrer" target="_blank">198.6.1.1</a> <a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a><br>
; (1 server found)<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43891<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 512<br>
;; QUESTION SECTION:<br>
;<a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a>. IN A<br>
<br>
;; ANSWER SECTION:<br>
<a href="http://labor.upload.akamai.com" rel="noreferrer" target="_blank">labor.upload.akamai.com</a>. 300 IN CNAME <a href="http://labor.c-ftp.upload.akamai.com" rel="noreferrer" target="_blank">labor.c-ftp.upload.akamai.com</a>.<br>
<a href="http://labor.c-ftp.upload.akamai.com" rel="noreferrer" target="_blank">labor.c-ftp.upload.akamai.com</a>. 900 IN CNAME <a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>.<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.137<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.149<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.144<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.143<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.142<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.148<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.139<br>
<a href="http://r33674-33729.neards.1.cftp.e.stor.lb.akamai.net" rel="noreferrer" target="_blank">r33674-33729.neards.1.cftp.e.stor.lb.akamai.net</a>. 23 IN A 23.200.4.146<br>
<br>
;; Query time: 202 msec<br>
;; SERVER: 198.6.1.1#53(198.6.1.1) (UDP)<br>
;; WHEN: Thu Feb 02 18:35:50 EST 2023<br>
;; MSG SIZE rcvd: 267<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>