Re: Intermittent issues resolving "labor.upload.akamai.com"
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 : type OPT Name: 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 = Reserved: 0x 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: 17e14f79ba23179d010063dc4895fbcf47353a31763c (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. 300IN 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 r
Re: Intermittent issues resolving "labor.upload.akamai.com"
Since the dig output shows "SERVFAIL" it could also be this bug: * When an outgoing request timed out, named would retry up to three times with the same server instead of trying the next available name server. This has been fixed. [GL #3637] that was fixed in 9.18.11 (https://bind9.readthedocs.io/en/v9_18_11/notes.html#bug-fixes) -- 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
Re: Requesting Update-Policy Statements Sanity Check, Please
You would probably need to attach your entire named.conf file (with
sensitive bits (keys and the like) redacted and perhaps subnets
obscured to examples such as 192.0.2.0/24, for example) before anyone
would be able to help you.
That being said, your update policy statements don't look correct to
me. Have you tried to load them with BIND? Do they pass syntax check?
The reason they don't look right is that they seem to follow this
format correctly:
# (grant | deny ) identity ruletype name types
but include the word "name" which I think is meant to be replaced
with your actual domain name (ie: I don't think the word "name" should
be in the policy).
I have not previously used update-policy but I'd think it should be like this:
update-policy {grant A ;};
from reading:
https://bind9.readthedocs.io/en/v9_18_11/reference.html#namedconf-statement-update-policy
--
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
Re: Requesting Update-Policy Statements Sanity Check, Please
You would probably need to attach your entire named.conf file (with sensitive bits (keys and the like) redacted named-checkconf -px is your friend: prints out the named.conf and included files in canonical form if no errors were detected and obscures shared secrets by replacing them with strings of question marks (?) -JP -- 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
Re: Requesting Update-Policy Statements Sanity Check, Please
> On 3 Feb 2023, at 21:47, Darren Ankney wrote:
>
> You would probably need to attach your entire named.conf file (with
> sensitive bits (keys and the like) redacted and perhaps subnets
> obscured to examples such as 192.0.2.0/24, for example) before anyone
> would be able to help you.
>
> That being said, your update policy statements don't look correct to
> me. Have you tried to load them with BIND? Do they pass syntax check?
> The reason they don't look right is that they seem to follow this
> format correctly:
>
> # (grant | deny ) identity ruletype name types
>
> but include the word "name" which I think is meant to be replaced
> with your actual domain name (ie: I don't think the word "name" should
> be in the policy).
No, “name” there is the rule type.
> I have not previously used update-policy but I'd think it should be like this:
>
> update-policy {grant A ;};
This leaves out rule type.
>
> from reading:
> https://bind9.readthedocs.io/en/v9_18_11/reference.html#namedconf-statement-update-policy
--
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
Re: Requesting Update-Policy Statements Sanity Check, Please
You need to replace the rule type with something more appropriate for the type
of update being preformed. For the updates made by the DHCP server I would use
“zonesub”. “name” is fine for LetsEncrypt.
update-policy {grant update-key zonesub A ;};
update-policy {grant update-key zonesub PTR;};
``zonesub``
This rule is similar to subdomain, except that it matches when the name
being updated is a subdomain of the zone in which the :any:`update-policy`
statement appears. This obviates the need to type the zone name twice, and
enables the use of a standard :any:`update-policy` statement in multiple zones
without modification. When this rule is used, the ``name`` field is omitted.
> On 3 Feb 2023, at 18:04, duluxoz wrote:
>
> Hi All,
>
> I'm pretty new to configuring Bind and so it would be great if someone(s)
> could just check my code re: the update-policy zone command(s) below - thanks
> in advance.
>
> For the first zone (a regular internal forward-lookup zone) I'd like to be
> able to update (from Kea via ddns) the zone when a new host is assigned/etc a
> DHCP lease:
>
> update-policy {grant update-key name internal-forward-lookup.local A ;};
>
> For the second zone (a regular internal reverse-lookup zone for the
> 192.168.1.0/24 network) I'd like to be able to update (from Kea via ddns) the
> zone when a new host is assigned a DHCP lease (obviously I've got an
> equivalent IPv6 reverse-lookup zone :-) ):
>
> update-policy {grant update-key name 1.168.192.IN-ADDR.ARPA PTR;};
>
> For the third zone (a regular external forward-lookup zone) I'd like to be
> able to update (via acme.sh/LetsEncrypt) the _acme-challenge.example.com TXT
> record when a Certificate is requested/renewed:
>
> update-policy {grant update-key name _acme-challenge.example.com TXT;};
>
> I've got the update-key configured and available on all the necessary boxes,
> etc, and dns (for fixed IP addresses) and dhcp are working - I just need to
> get these update-policy statements correct.
>
>
> Any help is greatly appreciated - and again, thanks in advance
>
> Cheers
>
> Dulux-Oz
--
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
