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,
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
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
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
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Ã
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
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
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
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
> 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
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
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
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
> 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.
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo
