Intermittent issues resolving "labor.upload.akamai.com"

Fri Feb 3 09:31:39 UTC 2023

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 at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230203/3755efee/attachment.htm>