I think you misunderstood me. I was getting back google.COM even when I
queried the server using nslookup from a command prompt on my Windows
desktop. The probe was failing because it is case-sensitive, but that was
the symptom, not the problem.
For example:
> google.com
Server: athena.bart.gov
A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Fri, 2016-03-25 at 22:15 -0400, Barry Margolin wrote:
> If you're running a resolver for a small organization, the cache isn't
> going to get huge in the first place. How many different names will 50
> users access in a day?
Looking at 6 such sma
On 30/03/2016 13:15, Tony Finch wrote:
Phil Mayers wrote:
On 30/03/16 10:50, Tony Finch wrote:
Yes, we encountered that problem recently :-) You can revert to the old
behaviour using
no-case-compress { any; };
+1 super confusing when we first ran into it (Exim dnslookup.c, by any c
On 30/03/2016 13:32, Mark Andrews wrote:
That said anything matching ownernames should be doing this case
insensitively.
Absolutely. In our case it was something a little more subtle - the app
(Exim) was actually looking for case-changed replies and altering its
input to match, which under c
On 30/03/2016 13:23, Tony Finch wrote:
Phil Mayers wrote:
What is considered the source of the ownername for, say, "com."?
It should be the root zone master file.
Doh, of course - brainfade, it should be the root.
I am mildly surprised that the root and TLD/2LD servers aren't doing the
r
In message <56fbbe83.6080...@imperial.ac.uk>, Phil Mayers writes:
> On 30/03/2016 12:25, Mark Andrews wrote:
>
> > The recent change was to record and return the learnt case of
> > ownernames (to the RRset level) rather than use whatever was used
> > to build the red-black tree names.
>
> What i
Phil Mayers wrote:
>
> What is considered the source of the ownername for, say, "com."?
It should be the root zone master file.
However authoritative server implementations differ in whether they echo
the query case or preserve the master case. e.g. a.root-servers.net
(running Verisign ATLAS) ec
Phil Mayers wrote:
> On 30/03/16 10:50, Tony Finch wrote:
> >
> > Yes, we encountered that problem recently :-) You can revert to the old
> > behaviour using
> >
> > no-case-compress { any; };
>
> +1 super confusing when we first ran into it (Exim dnslookup.c, by any
> chance? ;o)
Actually N
On 30/03/2016 12:25, Mark Andrews wrote:
The recent change was to record and return the learnt case of
ownernames (to the RRset level) rather than use whatever was used
to build the red-black tree names.
What is considered the source of the ownername for, say, "com."? One
thing I saw when I w
In message <56fbb385.5070...@imperial.ac.uk>, Phil Mayers writes:
> On 30/03/16 01:19, Mark Andrews wrote:
> >
> > Your monitoring probe is broken.
> >
> > STD 13 says that that the DNS is case preserving. The problem is
> > that lots of servers aren't case preserving instead they echo back
> > t
On 30/03/16 01:19, Mark Andrews wrote:
Your monitoring probe is broken.
STD 13 says that that the DNS is case preserving. The problem is
that lots of servers aren't case preserving instead they echo back
the query case in the owner names of records returned which named
then records.
Can I be
On 30/03/16 10:50, Tony Finch wrote:
Yes, we encountered that problem recently :-) You can revert to the old
behaviour using
no-case-compress { any; };
+1 super confusing when we first ran into it (Exim dnslookup.c, by any
chance? ;o)
In detail, since I spent ages figuring this ou
Mike Bernhardt wrote:
> I rebooted one of our BIND VMs this morning. It's running BIND 9.10.3-P3. We
> noticed that queries for domains with domain.com were answered with
> domain.COM with the .COM in capital letters. Other high-levels like .org
> were not changed. It caused a monitoring probe to
13 matches
Mail list logo
