Re: Request to use "Canonical/Mirror"
Also see https://datatracker.ietf.org/doc/html/rfc8499 for canonical DNS terminology document. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 14. 5. 2022, at 1:10, Felicia P wrote: > > Hello, I see that ISC updated terminology for BIND9 to use primary/secondary > in addition to the original master/slave which many projects have been > deprecating. > > In the context of BIND9, it seems that 'primary/secondary' is less clear than > master/slave. > > My understanding is that it is possible to have a standalone BIND server that > is running as a 'master' yet acting as a 'secondary' for a particular domain. > In this context, secondary doesn't necessarily refer to the 'slave' status > of the server, but that it is sort of like a backup server in the event that > the primary is unavailable. > > Given this, it seems like instead of 'primary/secondary', a better choice of > terms would be 'canonical/mirror' which unambiguously conveys the roles of > respective servers and does not overlap with other contexts or meanings of > primary/secondary. > > > > -- > 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
Re: Request to use "Canonical/Mirror"
On May 13, 2022, at 19.10, Felicia P wrote: > > Hello, I see that ISC updated terminology for BIND9 to use primary/secondary > in addition to the original master/slave which many projects have been > deprecating. > > In the context of BIND9, it seems that 'primary/secondary' is less clear than > master/slave. > > My understanding is that it is possible to have a standalone BIND server that > is running as a 'master' yet acting as a 'secondary' for a particular domain. > In this context, secondary doesn't necessarily refer to the 'slave' status > of the server, but that it is sort of like a backup server in the event that > the primary is unavailable. > > Given this, it seems like instead of 'primary/secondary', a better choice of > terms would be 'canonical/mirror' which unambiguously conveys the roles of > respective servers and does not overlap with other contexts or meanings of > primary/secondary. servers are neither master, nor slave, nor primary, nor secondary. zones are. -- 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: per record responses based on originating IP
On 13/05/22 09:02, Grant Taylor via bind-users wrote:
On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:
This sounds like exactly the sort of use case for Response Policy Zones:
How are you going to have RPZ return different addresses for different
clients? Are you suggesting use different RPZs with different
contents for different clients?
Yes, although now that I think through the details it turns out to be
much messier than I first thought, because there doesn't seem to be a
way to specify "not" in the RPZ...
Also I should point out that I'm assuming that a PASSTHRU result in one
RPZ will still result in subsequent RPZs being processed. I haven't
actually tested this, so its possible I'm misunderstanding the
documentation?
Anyway in the interests of following this all the way though, let's
assume you had 3 clients and you wanted them to each receive a different
answer to the query "www.example.com":
Suppose their IP addresses are:
A = 192.0.2.10
B = 192.0.2.20
C = 192.0.2.30
Then, if I'm not mistaken, you could create 3 RPZ zones:
Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc):
; Don't overwrite the answer for queries received from clients B & C
32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
; Change the answer to the question www.example.com
www.example.com IN A 10.0.0.1
Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc):
; Don't overwrite the answer for queries received from clients A & C
32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
; Change the answer to the question www.example.com
www.example.com IN A 10.0.0.2
Zone file for "c.rpz.mylocaldomain.com" contains (in addition to SOA, etc):
; Don't overwrite the answer for queries received from clients A & B
32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru.
; Change the answer to the question www.example.com
www.example.com IN A 10.0.0.3
And then configure BIND to use all three RPZs:
response-policy {
zone "a.rpz.mylocaldomain.com";
zone "b.rpz.mylocaldomain.com";
zone "c.rpz.mylocaldomain.com";
};
Scalability is obviously a challenge with this particular solution! :-(
So on reflection, there are probably better solutions to the problem
that you are trying to solve. Although I don't personally have
experience with it, wonder if "dnsmasq" might do what you need?
Thanks,
Nick.
--
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: Request to use "Canonical/Mirror"
Hello, I see that ISC updated terminology for BIND9 to use primary/secondary in addition to the original master/slave which many projects have been deprecating. In the context of BIND9, it seems that 'primary/secondary' is less clear than master/slave. My understanding is that it is possible to have a standalone BIND server that is running as a 'master' yet acting as a 'secondary' for a particular domain. In this context, secondary doesn't necessarily refer to the 'slave' status of the server, but that it is sort of like a backup server in the event that the primary is unavailable. Given this, it seems like instead of 'primary/secondary', a better choice of terms would be 'canonical/mirror' which unambiguously conveys the roles of respective servers and does not overlap with other contexts or meanings of primary/secondary. -- 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: Bind9 Server conflicts with docker0 interface
Hi folks, I have finally resolved my issue with docker interface.I had to delete my Ubuntu and install a brand new Centos on my server.Now everything works as expected. Cheers Em sábado, 7 de maio de 2022 06:23:32 GMT+1, Nick Tait via bind-users escreveu: On 7/05/2022 1:38 am, Maurà cio Penteado via bind-users wrote: > I added the A-record "ns1 IN A 172.17.0.1" to my zone-file as > suggested and it seems that the order fixed the issue. > Now my Bind9 clients are getting ip 192.168.0.10 favorably. Hi Mauricio. I don't think anyone suggested that you add that address to your zone file? My suggestion was to simply update the SOA serial number. Nick. -- 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
Re: Supporting LOC RR's
On 13-May-22 12:21, Philip Prindeville wrote: That's interesting, and clever work to solve the problem of making APs into reliable location references. They are doing a more involved/automated version of what I suggested - using GPS (in their case built-in GPS, plus AP-AP communication) for APs to locate themselves. Once the AP knows where it is, the clients can find out where they are in physical (WGS84 coordinate) space using the APs as references. Note that it's an enterprise solution - definitely not for most homes - since it requires at least 4, and probably many more suitable APs. But LOC records don't have any role in what's described. They *could* be an output (e.g. an AP could use DNS UPDATE to install LOC records). But there's still no obviously useful consumer for the LOCs...so why bother? If you're in WiFi range of the AP, a client is better off getting precise information from its broadcast. If not, it's useless. And as previously noted, LOC for servers suffers from AnyCast, cache, and CDN uncertainty. LOC was proposed in simpler times. Actually, if the AP doesn't have GPS but does offer WiFi Certified Location Service, then it could use its own LOC record to provision itself... -Philip WiFi Certified Location service computes the *relative* location of 2 WiFi devices. https://www.wi-fi.org/discover-wi-fi/wi-fi-location To offer an absolute location (what LOC provides), at least one AP has to know where it is (and broadcast it). Then additional APs can compute their positions relative to it, and compute their absolute location(s). Either your AP knows where it is, or it finds out via WCL (or some other means: e.g. GPS or configuration). If you want an AP to find out where it is via LOC, someone has to generate the LOC record. And the AP needs to be able to find it - meaning it has been configured with an IP address and/or name. If you want to participate in WCL, you want the LOC to have a precise (and accurate) position. OTOH, if an AP is participating in WCL and doesn't know its absolute location, it can compute it using WCL if some other AP knows and broadcasts its own absolute location. This conversation has come full circle. Where does the LOC record's position data come from, and who (or what) provisions it? And (assuming the AP doesn't have GPS or another reference, such as installed WCL APs) why is that easier/better than putting the data in the AP's config? As I noted, *after* an AP knows where it is, it *could* generate a LOC record, and even install it. But that makes it an *output* of provisioning, not an input. And there's still no obvious customer. Yes, some other AP could then use the first AP's LOC with WCL to determine its absolute location. (Well, you probably need three APs to triangulate...) But it's less work all around to get it from the first AP's broadcast. And you still have the bootstrapping problem. WCL clients have no use for LOC. If you want to map your APs, you can ask them for their locations directly. Much as some would like it to be, involving DNS isn't the answer to everything. If you still want to convince yourself that LOC is useful: starting with an empty building, some unprovisioned APs, and no LOC records, provide an algorithm that provisions your AP(s). Specify all inputs and where they come from. Contrast it with the HP video and/or manual configuration. Show what steps your algorithm eliminates and/or facilitates, and at what cost. I don't expect a positive outcome, but if I'm wrong, by all means post the details. Since this has indeed come full circle, I'm done. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- 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: Bind failures following update/reboot w/ 9.18.1
Your MTU is not the point. It's what happens beyond your equipment that may have a bearing. However, as I said, I don't think IP fragmentation will be your problem in this case, so that's a whole other discussion for a different day. pcaps are your friend though. From a packet capture you can see exactly what happened on the wire, rather than speculate. Cheers, Greg On Fri, 13 May 2022 at 18:00, Philip Prindeville < philipp_s...@redfish-solutions.com> wrote: > My MTU is 1500 bytes, so I don't think that's the problem. > > But UDP can fragment via IP... > > > > On May 13, 2022, at 10:34 AM, Greg Choules < > gregchoules+bindus...@googlemail.com> wrote: > > > > Hi Philip. > > Can you run packet captures? I'm running 9.18.0 (close enough?) in > Docker and just traced what happens going from "dnssec-validation no;" to > "dnssec-validation auto;" It makes a DNSKEY query for "." to one of the > roots. The response size was over 900 bytes, so depending on what UDP > payload size is advertised there might need to be some retrying over TCP. > But you'll only know whether that is happening from a pcap. > > So I'd say.. check EDNS payload size, check what your firewall(s) is/are > prepared to let through, check whether DNS/TCP is allowed at all, check if > something is doing IP fragmentation (though I wouldn't expect this to come > into play with a packet ~1k). > > > > I hope some of that is useful. > > Cheers, Greg > > > > On Fri, 13 May 2022 at 17:07, Philip Prindeville < > philipp_s...@redfish-solutions.com> wrote: > > After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started > seeing a lot of: > > > > > > May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid > signature found > > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid > signature found > > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > './NS/IN': 192.203.230.10#53 > > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'net/DS/IN': 8.8.4.4#53 > > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid > signature found > > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'com/DS/IN': 8.8.4.4#53 > > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid > signature found > > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'net/DS/IN': 66.232.64.10#53 > > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid > signature found > > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'com/DS/IN': 66.232.64.10#53 > > > > > > In my options, I had: > > > > dnssec-validation auto; > > > > But had to turn this off. It had been working. This is a production > firewall/router. > > > > What troubleshooting should I do to fix this? > > > > I had tried: > > > > rndc managed-keys refresh > > rndc managed-keys sync > > > > But don't understand why that would have been necessary unless the root > keys got updated recently. > > > > Scrolling to the very top of the logs I see: > > > > May 12 19:24:04 OpenWrt named[11061]: managed-keys-zone: Unable to fetch > DNSKEY set '.': timed out > > > > Thanks, > > > > -Philip > > > > > > -- > > 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
Re: Bind failures following update/reboot w/ 9.18.1
My MTU is 1500 bytes, so I don't think that's the problem. But UDP can fragment via IP... > On May 13, 2022, at 10:34 AM, Greg Choules > wrote: > > Hi Philip. > Can you run packet captures? I'm running 9.18.0 (close enough?) in Docker and > just traced what happens going from "dnssec-validation no;" to > "dnssec-validation auto;" It makes a DNSKEY query for "." to one of the > roots. The response size was over 900 bytes, so depending on what UDP payload > size is advertised there might need to be some retrying over TCP. But you'll > only know whether that is happening from a pcap. > So I'd say.. check EDNS payload size, check what your firewall(s) is/are > prepared to let through, check whether DNS/TCP is allowed at all, check if > something is doing IP fragmentation (though I wouldn't expect this to come > into play with a packet ~1k). > > I hope some of that is useful. > Cheers, Greg > > On Fri, 13 May 2022 at 17:07, Philip Prindeville > wrote: > After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started > seeing a lot of: > > > May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature > found > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature > found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving './NS/IN': > 192.203.230.10#53 > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': > 8.8.4.4#53 > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature > found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': > 8.8.4.4#53 > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature > found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': > 66.232.64.10#53 > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature > found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': > 66.232.64.10#53 > > > In my options, I had: > > dnssec-validation auto; > > But had to turn this off. It had been working. This is a production > firewall/router. > > What troubleshooting should I do to fix this? > > I had tried: > > rndc managed-keys refresh > rndc managed-keys sync > > But don't understand why that would have been necessary unless the root keys > got updated recently. > > Scrolling to the very top of the logs I see: > > May 12 19:24:04 OpenWrt named[11061]: managed-keys-zone: Unable to fetch > DNSKEY set '.': timed out > > Thanks, > > -Philip > > > -- > 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
Re: Bind failures following update/reboot w/ 9.18.1
Hi Philip. Can you run packet captures? I'm running 9.18.0 (close enough?) in Docker and just traced what happens going from "dnssec-validation no;" to "dnssec-validation auto;" It makes a DNSKEY query for "." to one of the roots. The response size was over 900 bytes, so depending on what UDP payload size is advertised there might need to be some retrying over TCP. But you'll only know whether that is happening from a pcap. So I'd say.. check EDNS payload size, check what your firewall(s) is/are prepared to let through, check whether DNS/TCP is allowed at all, check if something is doing IP fragmentation (though I wouldn't expect this to come into play with a packet ~1k). I hope some of that is useful. Cheers, Greg On Fri, 13 May 2022 at 17:07, Philip Prindeville < philipp_s...@redfish-solutions.com> wrote: > After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started > seeing a lot of: > > > May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature > found > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid > signature found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving './NS/IN': > 192.203.230.10#53 > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'net/DS/IN': 8.8.4.4#53 > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid > signature found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'com/DS/IN': 8.8.4.4#53 > May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid > signature found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'net/DS/IN': 66.232.64.10#53 > May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid > signature found > May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving > 'com/DS/IN': 66.232.64.10#53 > > > In my options, I had: > > dnssec-validation auto; > > But had to turn this off. It had been working. This is a production > firewall/router. > > What troubleshooting should I do to fix this? > > I had tried: > > rndc managed-keys refresh > rndc managed-keys sync > > But don't understand why that would have been necessary unless the root > keys got updated recently. > > Scrolling to the very top of the logs I see: > > May 12 19:24:04 OpenWrt named[11061]: managed-keys-zone: Unable to fetch > DNSKEY set '.': timed out > > Thanks, > > -Philip > > > -- > 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
Re: Supporting LOC RR's
> That's interesting, and clever work to solve the problem of making APs into > reliable location references. > > They are doing a more involved/automated version of what I suggested - using > GPS (in their case built-in GPS, plus AP-AP communication) for APs to locate > themselves. Once the AP knows where it is, the clients can find out where > they are in physical (WGS84 coordinate) space using the APs as references. > Note that it's an enterprise solution - definitely not for most homes - since > it requires at least 4, and probably many more suitable APs. > > But LOC records don't have any role in what's described. They *could* be an > output (e.g. an AP could use DNS UPDATE to install LOC records). But there's > still no obviously useful consumer for the LOCs...so why bother? > > If you're in WiFi range of the AP, a client is better off getting precise > information from its broadcast. If not, it's useless. And as previously > noted, LOC for servers suffers from AnyCast, cache, and CDN uncertainty. > > LOC was proposed in simpler times. Actually, if the AP doesn't have GPS but does offer WiFi Certified Location Service, then it could use its own LOC record to provision itself... -Philip -- 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
Bind failures following update/reboot w/ 9.18.1
After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started seeing a lot of: May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving './NS/IN': 192.203.230.10#53 May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': 8.8.4.4#53 May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': 8.8.4.4#53 May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': 66.232.64.10#53 May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': 66.232.64.10#53 In my options, I had: dnssec-validation auto; But had to turn this off. It had been working. This is a production firewall/router. What troubleshooting should I do to fix this? I had tried: rndc managed-keys refresh rndc managed-keys sync But don't understand why that would have been necessary unless the root keys got updated recently. Scrolling to the very top of the logs I see: May 12 19:24:04 OpenWrt named[11061]: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out Thanks, -Philip -- 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: Problem resolving a domain
Am 13.05.22 um 15:16 schrieb Rainer Duffner: Thanks for the hints! It does indeed work with these settings. The problem is also that google and quad9 and most of the rest of the internet seem to be able to resolve it the real problem is that they are working around it - if not the stupid upstream dns providers would have pressure to do their jobs and fix it at the root cause -- 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: Bad CNAME treatment consistency beetween direct CNAME request vs A request
Ok understood ! Do you have any opinion on the multi CNAME behavior at the authoritative server ? In python (in the analyzed case), the CNAME resolution will give you the second entry generating a dnssec validation failure. Yes it is a bit convoluted : - one program said "hey, this entry is a CNAME with this A value" the event (this is a CNAME) is recorded for later use. - another take the event and is only interested by the CNAME value and RRSIG and do a CNAME request. Boom... That is the origin of the "case". Thank you. Emmanuel. Le 13/05/2022 à 16:02, Ondřej Surý a écrit : I think you misdiagnosed the issue. Nothing asks directly for the CNAME under normal circumstances, and And IN A query returns: $ dig IN A lb.qual.flash-global.net @ns-160-c.gandi.net. ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A lb.qual.flash-global.net @ns-160-c.gandi.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56926 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN A ;; ANSWER SECTION: lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. lb1.qual.flash-global.net. 600 IN A 51.68.158.37 ;; Query time: 16 msec ;; SERVER: 217.70.187.161#53(ns-160-c.gandi.net.) (UDP) ;; WHEN: Fri May 13 15:57:49 CEST 2022 ;; MSG SIZE rcvd: 87 So, there’s nothing like “cache polution”, named correctly caches the records returned by the authoritative servers. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 13. 5. 2022, at 15:30, Emmanuel Fusté wrote: Hello, I've had a hard time identifying the source of intermittent name resolution failure for a customer. The source of the problem is a DNS spec violation with a RRSET with multiple CNAME: dig @ns-29-b.gandi.net CNAME lb.qual.flash-global.net ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @ns-29-b.gandi.net CNAME lb.qual.flash-global.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42945 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN CNAME ;; ANSWER SECTION: lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. lb.qual.flash-global.net. 10800 IN CNAME lb2.qual.flash-global.net. ;; Query time: 10 msec ;; SERVER: 213.167.230.30#53(ns-29-b.gandi.net) (UDP) ;; WHEN: Fri May 13 15:03:00 CEST 2022 ;; MSG SIZE rcvd: 89 If I try the resolution via my Bind (9.18.2) resolver, cache cold, it properly return a SERVFAIL: dig @172.29.0.36 +dnssec +cd CNAME lb.qual.flash-global.net ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @172.29.0.36 +dnssec +cd CNAME lb.qual.flash-global.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24053 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 23ac9b539bf16ad00100627e57c0b7d630e657322232 (good) ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN CNAME ;; Query time: 30 msec ;; SERVER: 172.29.0.36#53(172.29.0.36) (UDP) ;; WHEN: Fri May 13 15:06:09 CEST 2022 ;; MSG SIZE rcvd: 81 because the authoritative answer is correctly identified as invalid: named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': 213.167.230.30#53 named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': 217.70.187.161#53 named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': 173.246.100.82#53 Google DNS returns the same. If I do a A request, I get an (unexpected in my opinion) answer: dig @172.29.0.36 +dnssec +cd A lb.qual.flash-global.net ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @172.29.0.36 +dnssec +cd A lb.qual.flash-global.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26546 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: b5755aa921e65a440100627e58a481dbcf3655737b6b (good) ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN A ;; ANSWER SECTION: lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. lb.qual.flash-global.net. 10800 IN RRSIG CNAME 13 4 10800 2022052600 2022050500 57605 flash-global.net. NVDmeCSKkx998LRnmiB6hWz4PdZJ5WPG6CCrDTSP587pLUxxoxeNlCmJ l8l0p8/l8o+ZmZr1EXqxUA1FXpGbGw==
Re: Problem resolving a domain
> The problem is also that google and quad9 and most of the rest of the > internet seem to be able to resolve it. Yes, that’s **the problem**. There’s no pressure to get Barclays to fix this. If you are a customer, complain loudly. Advice your customers who are customers to complain loudly. They are non-compliant and need to deploy the fix at their side. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 13. 5. 2022, at 15:16, Rainer Duffner wrote: > > Hi, > > > Thanks for the hints! > > It does indeed work with these settings. > > The problem is also that google and quad9 and most of the rest of the > internet seem to be able to resolve it. > > > While I investigated this issue, I came around a posting from one or two > years ago where similar problems with Barclays were reported. > > And now, because I already spent too much time on this, I did a little > digging and found a few job descriptions on their site: > > > https://search.jobs.barclays/job/knutsford/network-connectivity-engineer/13015/26345992688 > > > So, they use Infoblox and F5 - though I guess the problem is more with the > firewall before these products… > > Funnily enough, this problem was a reported to us by an entity (a subsidiary > of our company) that uses Infoblox. > > I’m half-tempted to contact them so they can contact Barclays - but likely > neither side is going to bother - because „It works with Google-DNS“. > > > > > -- > 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 signature.asc Description: Message signed with OpenPGP -- 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: Bad CNAME treatment consistency beetween direct CNAME request vs A request
I think you misdiagnosed the issue. Nothing asks directly for the CNAME under normal circumstances, and And IN A query returns: $ dig IN A lb.qual.flash-global.net @ns-160-c.gandi.net. ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A lb.qual.flash-global.net @ns-160-c.gandi.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56926 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN A ;; ANSWER SECTION: lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. lb1.qual.flash-global.net. 600 IN A 51.68.158.37 ;; Query time: 16 msec ;; SERVER: 217.70.187.161#53(ns-160-c.gandi.net.) (UDP) ;; WHEN: Fri May 13 15:57:49 CEST 2022 ;; MSG SIZE rcvd: 87 So, there’s nothing like “cache polution”, named correctly caches the records returned by the authoritative servers. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 13. 5. 2022, at 15:30, Emmanuel Fusté wrote: > > Hello, > I've had a hard time identifying the source of intermittent name > resolution failure for a customer. > The source of the problem is a DNS spec violation with a RRSET with > multiple CNAME: > > dig @ns-29-b.gandi.net CNAME lb.qual.flash-global.net > > ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @ns-29-b.gandi.net > CNAME lb.qual.flash-global.net > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42945 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1232 > ;; QUESTION SECTION: > ;lb.qual.flash-global.net. IN CNAME > > ;; ANSWER SECTION: > lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. > lb.qual.flash-global.net. 10800 IN CNAME lb2.qual.flash-global.net. > > ;; Query time: 10 msec > ;; SERVER: 213.167.230.30#53(ns-29-b.gandi.net) (UDP) > ;; WHEN: Fri May 13 15:03:00 CEST 2022 > ;; MSG SIZE rcvd: 89 > > If I try the resolution via my Bind (9.18.2) resolver, cache cold, it > properly return a SERVFAIL: > dig @172.29.0.36 +dnssec +cd CNAME lb.qual.flash-global.net > > ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @172.29.0.36 > +dnssec +cd CNAME lb.qual.flash-global.net > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24053 > ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1232 > ; COOKIE: 23ac9b539bf16ad00100627e57c0b7d630e657322232 (good) > ;; QUESTION SECTION: > ;lb.qual.flash-global.net. IN CNAME > > ;; Query time: 30 msec > ;; SERVER: 172.29.0.36#53(172.29.0.36) (UDP) > ;; WHEN: Fri May 13 15:06:09 CEST 2022 > ;; MSG SIZE rcvd: 81 > > because the authoritative answer is correctly identified as invalid: > named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': > 213.167.230.30#53 > named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': > 217.70.187.161#53 > named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': > 173.246.100.82#53 > > Google DNS returns the same. > > If I do a A request, I get an (unexpected in my opinion) answer: > dig @172.29.0.36 +dnssec +cd A lb.qual.flash-global.net > > ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @172.29.0.36 > +dnssec +cd A lb.qual.flash-global.net > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26546 > ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1232 > ; COOKIE: b5755aa921e65a440100627e58a481dbcf3655737b6b (good) > ;; QUESTION SECTION: > ;lb.qual.flash-global.net. IN A > > ;; ANSWER SECTION: > lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. > lb.qual.flash-global.net. 10800 IN RRSIG CNAME 13 4 10800 > 2022052600 2022050500 57605 flash-global.net. > NVDmeCSKkx998LRnmiB6hWz4PdZJ5WPG6CCrDTSP587pLUxxoxeNlCmJ > l8l0p8/l8o+ZmZr1EXqxUA1FXpGbGw== > lb1.qual.flash-global.net. 600 IN A 51.68.158.37 > lb1.qual.flash-global.net. 600 IN RRSIG A 13 4 600 > 2022052600 2022050500 57605 flash-global.net. > G1YUaDtWVGxj5NbA18crQ912tW/VWra49wi3U1EeRio9kId+2mwo7Vuj > GH8adlvvjQyps7IBtj9gYVmbewN+GQ== > > ;; Query time: 30 msec > ;; SERVER: 172.29.0.36#53(172.29.0.36) (UDP) > ;; WHEN: Fri May 13 15:09:57 CEST 2022 > ;; MSG SIZE rcvd: 339 > > Google DNS do the
Bad CNAME treatment consistency beetween direct CNAME request vs A request
Hello, I've had a hard time identifying the source of intermittent name resolution failure for a customer. The source of the problem is a DNS spec violation with a RRSET with multiple CNAME: dig @ns-29-b.gandi.net CNAME lb.qual.flash-global.net ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @ns-29-b.gandi.net CNAME lb.qual.flash-global.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42945 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN CNAME ;; ANSWER SECTION: lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. lb.qual.flash-global.net. 10800 IN CNAME lb2.qual.flash-global.net. ;; Query time: 10 msec ;; SERVER: 213.167.230.30#53(ns-29-b.gandi.net) (UDP) ;; WHEN: Fri May 13 15:03:00 CEST 2022 ;; MSG SIZE rcvd: 89 If I try the resolution via my Bind (9.18.2) resolver, cache cold, it properly return a SERVFAIL: dig @172.29.0.36 +dnssec +cd CNAME lb.qual.flash-global.net ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @172.29.0.36 +dnssec +cd CNAME lb.qual.flash-global.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24053 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 23ac9b539bf16ad00100627e57c0b7d630e657322232 (good) ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN CNAME ;; Query time: 30 msec ;; SERVER: 172.29.0.36#53(172.29.0.36) (UDP) ;; WHEN: Fri May 13 15:06:09 CEST 2022 ;; MSG SIZE rcvd: 81 because the authoritative answer is correctly identified as invalid: named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': 213.167.230.30#53 named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': 217.70.187.161#53 named[147998]: FORMERR resolving 'lb.qual.flash-global.net/CNAME/IN': 173.246.100.82#53 Google DNS returns the same. If I do a A request, I get an (unexpected in my opinion) answer: dig @172.29.0.36 +dnssec +cd A lb.qual.flash-global.net ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @172.29.0.36 +dnssec +cd A lb.qual.flash-global.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26546 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: b5755aa921e65a440100627e58a481dbcf3655737b6b (good) ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN A ;; ANSWER SECTION: lb.qual.flash-global.net. 10800 IN CNAME lb1.qual.flash-global.net. lb.qual.flash-global.net. 10800 IN RRSIG CNAME 13 4 10800 2022052600 2022050500 57605 flash-global.net. NVDmeCSKkx998LRnmiB6hWz4PdZJ5WPG6CCrDTSP587pLUxxoxeNlCmJ l8l0p8/l8o+ZmZr1EXqxUA1FXpGbGw== lb1.qual.flash-global.net. 600 IN A 51.68.158.37 lb1.qual.flash-global.net. 600 IN RRSIG A 13 4 600 2022052600 2022050500 57605 flash-global.net. G1YUaDtWVGxj5NbA18crQ912tW/VWra49wi3U1EeRio9kId+2mwo7Vuj GH8adlvvjQyps7IBtj9gYVmbewN+GQ== ;; Query time: 30 msec ;; SERVER: 172.29.0.36#53(172.29.0.36) (UDP) ;; WHEN: Fri May 13 15:09:57 CEST 2022 ;; MSG SIZE rcvd: 339 Google DNS do the same BUT Now on my side I have cache pollution as a new CNAME request give me dig @172.29.0.36 +dnssec +cd CNAME lb.qual.flash-global.net ; <<>> DiG 9.18.2-1+ubuntu20.04.1+isc+3-Ubuntu <<>> @172.29.0.36 +dnssec +cd CNAME lb.qual.flash-global.net ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42637 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: ea748ef065e32df10100627e59947b2e1424679d72f2 (good) ;; QUESTION SECTION: ;lb.qual.flash-global.net. IN CNAME ;; ANSWER SECTION: lb.qual.flash-global.net. 10560 IN CNAME lb1.qual.flash-global.net. lb.qual.flash-global.net. 10560 IN RRSIG CNAME 13 4 10800 2022052600 2022050500 57605 flash-global.net. NVDmeCSKkx998LRnmiB6hWz4PdZJ5WPG6CCrDTSP587pLUxxoxeNlCmJ l8l0p8/l8o+ZmZr1EXqxUA1FXpGbGw== ;; Query time: 20 msec ;; SERVER: 172.29.0.36#53(172.29.0.36) (UDP) ;; WHEN: Fri May 13 15:13:56 CEST 2022 ;; MSG SIZE rcvd: 211 until I issue a rndc flush command. This cache pollution is bad and seems to not happen on the google side (but there are many DNS behind 8.8.8.8). I would have expected a SERVFAIL/FORMERR in the A request case. Even if I could understand a conservative approach from the Google side, I don't buy it for Bind and expect a configuration directive to reject it. If this (the A case) is an expected behavior for Bind, I
Re: Problem resolving a domain
Hi, Thanks for the hints! It does indeed work with these settings. The problem is also that google and quad9 and most of the rest of the internet seem to be able to resolve it. While I investigated this issue, I came around a posting from one or two years ago where similar problems with Barclays were reported. And now, because I already spent too much time on this, I did a little digging and found a few job descriptions on their site: https://search.jobs.barclays/job/knutsford/network-connectivity-engineer/13015/26345992688 So, they use Infoblox and F5 - though I guess the problem is more with the firewall before these products… Funnily enough, this problem was a reported to us by an entity (a subsidiary of our company) that uses Infoblox. I’m half-tempted to contact them so they can contact Barclays - but likely neither side is going to bother - because „It works with Google-DNS“. -- 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: Problem resolving a domain
Agreed, but without the upstream provider actually fixing the issue I
couldn't find a way to provide resolution of this domain to my customers -
are there better ways to resolve this from our side?
There seems to be a document about this issue -
https://kb.isc.org/docs/aa-01387
Paul
On Fri, 13 May 2022 at 14:07, Mark Andrews wrote:
> Working around servers that drop queries causes problems for zones that do
> have protocol compliant servers. The workarounds cause problems with
> getting DNSSEC responses wic leads to validation failures.
>
> --
> Mark Andrews
>
> On 13 May 2022, at 22:58, Paul Stead wrote:
>
>
> Further to this, I've discovered that disabling DNS cookies also seems to
> help with resolution -
>
> $ dig +nocookie +timeout=1 +retries=0 IN A
> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>
> Maybe the send-cookie option could be investigated? YMMV..
>
> On a side note other recursive DNS software seem to fall back gracefully
> and resolve these problems
>
> Paul
>
> On Fri, 13 May 2022 at 13:51, Paul Stead wrote:
>
>> I have noticed this, too,
>>
>> The problem seems to be related to edns - disabling edns for the upstream
>> servers looks to resolve the issue, this can be seen with later versions of
>> dig -
>>
>> $ dig *+noedns* +timeout=1 +retries=0 IN A
>> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>>
>> I have config along the lines of -
>>
>> server 157.83.102.245 {
>> edns no;
>> };
>>
>> for each of the problematic upstreams. I contacted Barclays a few months
>> ago about this, but never got a solid response.
>>
>> Paul
>>
>> On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
>>
>>> Hi Rainer,
>>>
>>> I believe this is unrelated to any upgrade. The nameservers for the
>>> domain are broken:
>>>
>>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>>> myapplication.international.barclays.com @ns2.barcap.com.
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>>> ;; WARNING: recursion requested but not available
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1220
>>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>>> ;; QUESTION SECTION:
>>> ;myapplication.international.barclays.com. IN A
>>>
>>> ;; ANSWER SECTION:
>>> myapplication.international.barclays.com. 900 IN CNAME
>>> myapplication.glbaa.barclays.com.
>>>
>>> ;; AUTHORITY SECTION:
>>> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
>>> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>>>
>>> ;; ADDITIONAL SECTION:
>>> ns21.barclays.com. 900 IN A 157.83.102.245
>>> ns23.barclays.com. 900 IN A 157.83.126.245
>>> ns22.barclays.net. 600 IN A 157.83.102.246
>>> ns24.barclays.net. 600 IN A 157.83.126.246
>>>
>>> ;; Query time: 196 msec
>>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>>> ;; MSG SIZE rcvd: 283
>>>
>>>
>>> and the nameservers itself just timeout:
>>>
>>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
>>> ns21.barclays.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
>>> +timeout +retries IN A myapplication.glbaa.barclays.com. @
>>> ns21.barclays.com.
>>> ;; global options: +cmd
>>> ;; connection timed out; no servers could be reached
>>>
>>>
>>> DNSVIZ gives the same result:
>>>
>>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>>
>>> • glbaa.barclays.com zone: The server(s) were not responsive to
>>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>>> 157.83.126.246)
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý (He/Him)
>>> ond...@isc.org
>>>
>>> My working hours and your working hours may be different. Please do not
>>> feel obligated to reply outside your normal working hours.
>>>
>>> > On 13. 5. 2022, at 13:54, Rainer Duffner
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > at work, I have a problem resolving the following domain:
>>> >
>>> > myapplication.international.barclays.com
>>> >
>>> >
>>> > BIND 9.16.27, FreeBSD 12.3-P5.
>>> > 2022Q2 ports.
>>> >
>>> >
>>> > I copied the config to a VM at home - but it did not work there,
>>> either.
>>> >
>>> > I believe it must have happened on the update from BIND 9.16.26 to
>>> 9.16.27.
>>> >
>>> >
>>> > options {
>>> >directory "/usr/local/etc/namedb/working";
>>> >pid-file"/var/run/named/pid";
>>> >dump-file "/var/dump/named_dump.db";
>>> >statistics-file "/var/stats/named.stats";
>>> >allow-recursion {"rec";};
>>> >
Re: Problem resolving a domain
Working around servers that drop queries causes problems for zones that do have
protocol compliant servers. The workarounds cause problems with getting
DNSSEC responses wic leads to validation failures.
--
Mark Andrews
> On 13 May 2022, at 22:58, Paul Stead wrote:
>
>
> Further to this, I've discovered that disabling DNS cookies also seems to
> help with resolution -
>
> $ dig +nocookie +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
> @ns21.barclays.com.
>
> Maybe the send-cookie option could be investigated? YMMV..
>
> On a side note other recursive DNS software seem to fall back gracefully and
> resolve these problems
>
> Paul
>
> On Fri, 13 May 2022 at 13:51, Paul Stead wrote:
>> I have noticed this, too,
>>
>> The problem seems to be related to edns - disabling edns for the upstream
>> servers looks to resolve the issue, this can be seen with later versions of
>> dig -
>>
>> $ dig +noedns +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
>> @ns21.barclays.com.
>>
>> I have config along the lines of -
>>
>> server 157.83.102.245 {
>> edns no;
>> };
>>
>> for each of the problematic upstreams. I contacted Barclays a few months ago
>> about this, but never got a solid response.
>>
>> Paul
>>
>> On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
>>> Hi Rainer,
>>>
>>> I believe this is unrelated to any upgrade. The nameservers for the domain
>>> are broken:
>>>
>>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>>> myapplication.international.barclays.com @ns2.barcap.com.
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>>> ;; WARNING: recursion requested but not available
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 1220
>>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>>> ;; QUESTION SECTION:
>>> ;myapplication.international.barclays.com. IN A
>>>
>>> ;; ANSWER SECTION:
>>> myapplication.international.barclays.com. 900 IN CNAME
>>> myapplication.glbaa.barclays.com.
>>>
>>> ;; AUTHORITY SECTION:
>>> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
>>> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
>>> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>>>
>>> ;; ADDITIONAL SECTION:
>>> ns21.barclays.com. 900 IN A 157.83.102.245
>>> ns23.barclays.com. 900 IN A 157.83.126.245
>>> ns22.barclays.net. 600 IN A 157.83.102.246
>>> ns24.barclays.net. 600 IN A 157.83.126.246
>>>
>>> ;; Query time: 196 msec
>>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>>> ;; MSG SIZE rcvd: 283
>>>
>>>
>>> and the nameservers itself just timeout:
>>>
>>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
>>> @ns21.barclays.com.
>>>
>>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> +timeout
>>> +retries IN A myapplication.glbaa.barclays.com. @ns21.barclays.com.
>>> ;; global options: +cmd
>>> ;; connection timed out; no servers could be reached
>>>
>>>
>>> DNSVIZ gives the same result:
>>>
>>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>>
>>> • glbaa.barclays.com zone: The server(s) were not responsive to
>>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>>> 157.83.126.246)
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý (He/Him)
>>> ond...@isc.org
>>>
>>> My working hours and your working hours may be different. Please do not
>>> feel obligated to reply outside your normal working hours.
>>>
>>> > On 13. 5. 2022, at 13:54, Rainer Duffner wrote:
>>> >
>>> > Hi,
>>> >
>>> > at work, I have a problem resolving the following domain:
>>> >
>>> > myapplication.international.barclays.com
>>> >
>>> >
>>> > BIND 9.16.27, FreeBSD 12.3-P5.
>>> > 2022Q2 ports.
>>> >
>>> >
>>> > I copied the config to a VM at home - but it did not work there, either.
>>> >
>>> > I believe it must have happened on the update from BIND 9.16.26 to
>>> > 9.16.27.
>>> >
>>> >
>>> > options {
>>> >directory "/usr/local/etc/namedb/working";
>>> >pid-file"/var/run/named/pid";
>>> >dump-file "/var/dump/named_dump.db";
>>> >statistics-file "/var/stats/named.stats";
>>> >allow-recursion {"rec";};
>>> >allow-query-cache { localhost; "rec" ; };
>>> >// CIS recommended:
>>> >// serverid none;
>>> >// dnssec-enable yes;
>>> >// dnssec-validation auto;
>>> >// dnssec-accept-expired no;
>>> >
>>> >listen-on { 192.168.1.61; };
>>> >
>>> >
Re: Problem resolving a domain
Further to this, I've discovered that disabling DNS cookies also seems to
help with resolution -
$ dig +nocookie +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.
Maybe the send-cookie option could be investigated? YMMV..
On a side note other recursive DNS software seem to fall back gracefully
and resolve these problems
Paul
On Fri, 13 May 2022 at 13:51, Paul Stead wrote:
> I have noticed this, too,
>
> The problem seems to be related to edns - disabling edns for the upstream
> servers looks to resolve the issue, this can be seen with later versions of
> dig -
>
> $ dig *+noedns* +timeout=1 +retries=0 IN A
> myapplication.glbaa.barclays.com. @ns21.barclays.com.
>
> I have config along the lines of -
>
> server 157.83.102.245 {
> edns no;
> };
>
> for each of the problematic upstreams. I contacted Barclays a few months
> ago about this, but never got a solid response.
>
> Paul
>
> On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
>
>> Hi Rainer,
>>
>> I believe this is unrelated to any upgrade. The nameservers for the
>> domain are broken:
>>
>> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>>
>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
>> myapplication.international.barclays.com @ns2.barcap.com.
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
>> ;; WARNING: recursion requested but not available
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 1220
>> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
>> ;; QUESTION SECTION:
>> ;myapplication.international.barclays.com. IN A
>>
>> ;; ANSWER SECTION:
>> myapplication.international.barclays.com. 900 IN CNAME
>> myapplication.glbaa.barclays.com.
>>
>> ;; AUTHORITY SECTION:
>> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
>> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
>> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
>> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>>
>> ;; ADDITIONAL SECTION:
>> ns21.barclays.com. 900 IN A 157.83.102.245
>> ns23.barclays.com. 900 IN A 157.83.126.245
>> ns22.barclays.net. 600 IN A 157.83.102.246
>> ns24.barclays.net. 600 IN A 157.83.126.246
>>
>> ;; Query time: 196 msec
>> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
>> ;; WHEN: Fri May 13 14:08:49 CEST 2022
>> ;; MSG SIZE rcvd: 283
>>
>>
>> and the nameservers itself just timeout:
>>
>> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
>> ns21.barclays.com.
>>
>> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
>> +timeout +retries IN A myapplication.glbaa.barclays.com. @
>> ns21.barclays.com.
>> ;; global options: +cmd
>> ;; connection timed out; no servers could be reached
>>
>>
>> DNSVIZ gives the same result:
>>
>> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>>
>> • glbaa.barclays.com zone: The server(s) were not responsive to
>> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
>> 157.83.126.246)
>>
>> Ondrej
>> --
>> Ondřej Surý (He/Him)
>> ond...@isc.org
>>
>> My working hours and your working hours may be different. Please do not
>> feel obligated to reply outside your normal working hours.
>>
>> > On 13. 5. 2022, at 13:54, Rainer Duffner
>> wrote:
>> >
>> > Hi,
>> >
>> > at work, I have a problem resolving the following domain:
>> >
>> > myapplication.international.barclays.com
>> >
>> >
>> > BIND 9.16.27, FreeBSD 12.3-P5.
>> > 2022Q2 ports.
>> >
>> >
>> > I copied the config to a VM at home - but it did not work there, either.
>> >
>> > I believe it must have happened on the update from BIND 9.16.26 to
>> 9.16.27.
>> >
>> >
>> > options {
>> >directory "/usr/local/etc/namedb/working";
>> >pid-file"/var/run/named/pid";
>> >dump-file "/var/dump/named_dump.db";
>> >statistics-file "/var/stats/named.stats";
>> >allow-recursion {"rec";};
>> >allow-query-cache { localhost; "rec" ; };
>> >// CIS recommended:
>> >// serverid none;
>> >// dnssec-enable yes;
>> >// dnssec-validation auto;
>> >// dnssec-accept-expired no;
>> >
>> >listen-on { 192.168.1.61; };
>> >
>> >disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
>> >disable-empty-zone
>> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>> >disable-empty-zone
>> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>> >
>> > };
>> >
>> > acl rec {
>> >127.0.0.0/8;
>> >192.168.1.0/24;
>> >::1;
>> > };
>> >
>> > /* Serving the following zones locally will prevent any queries
>> >for these zones
Re: Problem resolving a domain
I have noticed this, too,
The problem seems to be related to edns - disabling edns for the upstream
servers looks to resolve the issue, this can be seen with later versions of
dig -
$ dig *+noedns* +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.
I have config along the lines of -
server 157.83.102.245 {
edns no;
};
for each of the problematic upstreams. I contacted Barclays a few months
ago about this, but never got a solid response.
Paul
On Fri, 13 May 2022 at 13:12, Ondřej Surý wrote:
> Hi Rainer,
>
> I believe this is unrelated to any upgrade. The nameservers for the domain
> are broken:
>
> $ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
>
> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
> myapplication.international.barclays.com @ns2.barcap.com.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1220
> ; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
> ;; QUESTION SECTION:
> ;myapplication.international.barclays.com. IN A
>
> ;; ANSWER SECTION:
> myapplication.international.barclays.com. 900 IN CNAME
> myapplication.glbaa.barclays.com.
>
> ;; AUTHORITY SECTION:
> glbaa.barclays.com. 900 IN NS ns22.barclays.net.
> glbaa.barclays.com. 900 IN NS ns21.barclays.com.
> glbaa.barclays.com. 900 IN NS ns24.barclays.net.
> glbaa.barclays.com. 900 IN NS ns23.barclays.com.
>
> ;; ADDITIONAL SECTION:
> ns21.barclays.com. 900 IN A 157.83.102.245
> ns23.barclays.com. 900 IN A 157.83.126.245
> ns22.barclays.net. 600 IN A 157.83.102.246
> ns24.barclays.net. 600 IN A 157.83.126.246
>
> ;; Query time: 196 msec
> ;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
> ;; WHEN: Fri May 13 14:08:49 CEST 2022
> ;; MSG SIZE rcvd: 283
>
>
> and the nameservers itself just timeout:
>
> $ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com. @
> ns21.barclays.com.
>
> ; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>>
> +timeout +retries IN A myapplication.glbaa.barclays.com. @
> ns21.barclays.com.
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
>
>
> DNSVIZ gives the same result:
>
> https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
>
> • glbaa.barclays.com zone: The server(s) were not responsive to
> queries over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245,
> 157.83.126.246)
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
>
> > On 13. 5. 2022, at 13:54, Rainer Duffner wrote:
> >
> > Hi,
> >
> > at work, I have a problem resolving the following domain:
> >
> > myapplication.international.barclays.com
> >
> >
> > BIND 9.16.27, FreeBSD 12.3-P5.
> > 2022Q2 ports.
> >
> >
> > I copied the config to a VM at home - but it did not work there, either.
> >
> > I believe it must have happened on the update from BIND 9.16.26 to
> 9.16.27.
> >
> >
> > options {
> >directory "/usr/local/etc/namedb/working";
> >pid-file"/var/run/named/pid";
> >dump-file "/var/dump/named_dump.db";
> >statistics-file "/var/stats/named.stats";
> >allow-recursion {"rec";};
> >allow-query-cache { localhost; "rec" ; };
> >// CIS recommended:
> >// serverid none;
> >// dnssec-enable yes;
> >// dnssec-validation auto;
> >// dnssec-accept-expired no;
> >
> >listen-on { 192.168.1.61; };
> >
> >disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
> >disable-empty-zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
> >disable-empty-zone
> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
> >
> > };
> >
> > acl rec {
> >127.0.0.0/8;
> >192.168.1.0/24;
> >::1;
> > };
> >
> > /* Serving the following zones locally will prevent any queries
> >for these zones leaving your network and going to the root
> >name servers. This has two significant advantages:
> >1. Faster local resolution for your users
> >2. No spurious traffic will be sent from your network to the roots
> > */
> > // RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
> > zone "localhost"{ type master; file
> "/usr/local/etc/namedb/master/localhost-forward.db"; };
> > zone "127.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/localhost-reverse.db"; };
> > zone "255.in-addr.arpa" { type master; file
>
Re: Problem resolving a domain
Hi Rainer,
I believe this is unrelated to any upgrade. The nameservers for the domain are
broken:
$ dig IN A myapplication.international.barclays.com @ns2.barcap.com.
; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> IN A
myapplication.international.barclays.com @ns2.barcap.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26288
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 1154fcda62fc8122973932b0627e4a9e96eef4cf1d850adf (good)
;; QUESTION SECTION:
;myapplication.international.barclays.com. IN A
;; ANSWER SECTION:
myapplication.international.barclays.com. 900 IN CNAME
myapplication.glbaa.barclays.com.
;; AUTHORITY SECTION:
glbaa.barclays.com. 900 IN NS ns22.barclays.net.
glbaa.barclays.com. 900 IN NS ns21.barclays.com.
glbaa.barclays.com. 900 IN NS ns24.barclays.net.
glbaa.barclays.com. 900 IN NS ns23.barclays.com.
;; ADDITIONAL SECTION:
ns21.barclays.com. 900 IN A 157.83.102.245
ns23.barclays.com. 900 IN A 157.83.126.245
ns22.barclays.net. 600 IN A 157.83.102.246
ns24.barclays.net. 600 IN A 157.83.126.246
;; Query time: 196 msec
;; SERVER: 141.228.196.129#53(ns2.barcap.com.) (UDP)
;; WHEN: Fri May 13 14:08:49 CEST 2022
;; MSG SIZE rcvd: 283
and the nameservers itself just timeout:
$ dig +timeout=1 +retries=0 IN A myapplication.glbaa.barclays.com.
@ns21.barclays.com.
; <<>> DiG 9.19.0-1+0~20220421.76+debian10~1.gbpa71ef8-Debian <<>> +timeout
+retries IN A myapplication.glbaa.barclays.com. @ns21.barclays.com.
;; global options: +cmd
;; connection timed out; no servers could be reached
DNSVIZ gives the same result:
https://dnsviz.net/d/myapplication.glbaa.barclays.com/dnssec/
• glbaa.barclays.com zone: The server(s) were not responsive to queries
over UDP. (157.83.102.245, 157.83.102.246, 157.83.126.245, 157.83.126.246)
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 13. 5. 2022, at 13:54, Rainer Duffner wrote:
>
> Hi,
>
> at work, I have a problem resolving the following domain:
>
> myapplication.international.barclays.com
>
>
> BIND 9.16.27, FreeBSD 12.3-P5.
> 2022Q2 ports.
>
>
> I copied the config to a VM at home - but it did not work there, either.
>
> I believe it must have happened on the update from BIND 9.16.26 to 9.16.27.
>
>
> options {
>directory "/usr/local/etc/namedb/working";
>pid-file"/var/run/named/pid";
>dump-file "/var/dump/named_dump.db";
>statistics-file "/var/stats/named.stats";
>allow-recursion {"rec";};
>allow-query-cache { localhost; "rec" ; };
>// CIS recommended:
>// serverid none;
>// dnssec-enable yes;
>// dnssec-validation auto;
>// dnssec-accept-expired no;
>
>listen-on { 192.168.1.61; };
>
>disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
>disable-empty-zone
> "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>disable-empty-zone
> "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
>
> };
>
> acl rec {
>127.0.0.0/8;
>192.168.1.0/24;
>::1;
> };
>
> /* Serving the following zones locally will prevent any queries
>for these zones leaving your network and going to the root
>name servers. This has two significant advantages:
>1. Faster local resolution for your users
>2. No spurious traffic will be sent from your network to the roots
> */
> // RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
> zone "localhost"{ type master; file
> "/usr/local/etc/namedb/master/localhost-forward.db"; };
> zone "127.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/localhost-reverse.db"; };
> zone "255.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
>
> // RFC 1912-style zone for IPv6 localhost address (RFC 6303)
> zone "0.ip6.arpa" { type master; file
> "/usr/local/etc/namedb/master/localhost-reverse.db"; };
>
> // "This" Network (RFCs 1912, 5735 and 6303)
> zone "0.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
>
> // Private Use Networks (RFCs 1918, 5735 and 6303)
> zone "10.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
> zone "16.172.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
> zone "17.172.in-addr.arpa" { type master; file
> "/usr/local/etc/namedb/master/empty.db"; };
> zone "18.172.in-addr.arpa" { type master; file
>
Problem resolving a domain
Hi,
at work, I have a problem resolving the following domain:
myapplication.international.barclays.com
BIND 9.16.27, FreeBSD 12.3-P5.
2022Q2 ports.
I copied the config to a VM at home - but it did not work there, either.
I believe it must have happened on the update from BIND 9.16.26 to 9.16.27.
options {
directory "/usr/local/etc/namedb/working";
pid-file"/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
allow-recursion {"rec";};
allow-query-cache { localhost; "rec" ; };
// CIS recommended:
// serverid none;
// dnssec-enable yes;
// dnssec-validation auto;
// dnssec-accept-expired no;
listen-on { 192.168.1.61; };
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
};
acl rec {
127.0.0.0/8;
192.168.1.0/24;
::1;
};
/* Serving the following zones locally will prevent any queries
for these zones leaving your network and going to the root
name servers. This has two significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
*/
// RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
zone "localhost"{ type master; file
"/usr/local/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// RFC 1912-style zone for IPv6 localhost address (RFC 6303)
zone "0.ip6.arpa" { type master; file
"/usr/local/etc/namedb/master/localhost-reverse.db"; };
// "This" Network (RFCs 1912, 5735 and 6303)
zone "0.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// Private Use Networks (RFCs 1918, 5735 and 6303)
zone "10.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// Shared Address Space (RFC 6598)
zone "64.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "65.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "66.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "67.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "68.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "69.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "70.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "71.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "72.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "73.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "74.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "75.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "76.100.in-addr.arpa" {
