Re: response case in-sensitivity?

[Mark Andrews]

In message <23dee83f-7476-432b-92b9-f8d34d617...@nau.edu>, Mathew Ian Eis 
writes:
> Howdy BIND,
> 
> Weve been troubleshooting an issue with iOS print discovery using DNS-SD 
> for the last several weeks. We made a little bit of a breakthrough this 
> evening when we observed in a packet trace that the response case was 
> fully lowercase, regardless of the query case. It seems iOS is doing some 
> kind of case sensitive comparison between the query and the response, 
> causing DNS-SD to fail when they dont match.

Then iOS (or the application) is broken.  Domain names should always
be compared case insensitively.  Please report a bug to the app
vendor and / or Apple.

> I noticed change 3645, but my reading of the related article suggests 
> that the change was actually intended to preserve the case in a query 
> response rather than force it to lowercase.

It preserves the case of the of the owner names of the records in
the answers as received.

> My reading of that article suggests the RFC compliant behavior is to 
> preserve the case in the response, is this correct? 
> https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-C
> ompression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clie
> nts.html
> 
> Were currently running BIND 9.9.7 (it is likely this issue was introduced 
> when we updated from 9.9.4 a while back), so Im wondering why I am 
> running into this. Is there something that I need to turn on to preserve 
> the case in the response, or, alternatively, is there something that we 
> have have inadvertently changed that would cause BIND to force the 
> response to lowercase?
> 
> Thanks in advance,
> 
> Mathew Eis
> Northern Arizona University
> Information Technology Services
> mathew@nau.edu

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: response case in-sensitivity?

[Hauke Lampe]

On 30.07.2015 03:02, Mathew Ian Eis wrote:

> My reading of that article suggests the RFC compliant behavior is to preserve 
> the case in the response, is this correct? 
> https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clients.html

I never quite understood DNS compression rules but I can confirm what
you see with BIND 9.10.2 and that the ACL mentioned in the comments
changes the behaviour.

The responses matches the case of the cached entry:

SRV? _xmpp-server._TCP.hauke-lampe.de. (61)
1/4/9 _xmpp-server._TCP.hauke-lampe.de. SRV jabber2

SRV? _xMpP-ServeR._tCp.haukE-lampE.de. (61)
1/4/9 _xmpp-server._TCP.hauke-lampe.de. SRV jabber2


with "no-case-compress { any; };":

SRV? _xmpp-server._TCP.hauke-lampe.de. (61)
1/4/9 _xmpp-server._TCP.hauke-lampe.de. SRV jabber2

SRV? _xMpP-ServeR._tCp.haukE-lampE.de. (61)
1/4/9 _xMpP-ServeR._tCp.haukE-lampE.de. SRV jabber2

["This new ACL is going to be available in 9.10.0 (noted already as
being in 9.10.0b1), 9.9.6, and 9.8.8, as well as in subscription
versions of BIND."]


Hauke.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: do not stupidly delete ZSK files

[David Newman]

On 7/29/15 6:24 PM, Evan Hunt wrote:
> On Wed, Jul 29, 2015 at 05:56:20PM -0700, David Newman wrote:
>> 29-Jul-2015 17:18:19.439 general: warning:
>> dns_dnssec_keylistfromrdataset: error reading private key file
>> example.com/RSASHA256/36114: file not found
> 
> Delete that key from the DNSKEY rrset in the zone and reload.
> 
> If it's a dynamic zone, freeze it first, then edit the zone file,
> delete the key, increase the serial number, and thaw it.
> 
> If it's not dynamic, same instructions, but without the freezing
> and thawing.

Thanks very much.

It's a static zone. The zone file did not have the key in it.

I dumped the signed file like this:

named-compilezone -f raw -F text -o example.com.text example.com
example.com.db.signed

Then incremented the serial number and copied that over to the zone file
(after making a backup copy).

Same complaint in the log when reloading, though.

What else is required to get rid of this nonexistent key?

Thanks again

dn


in named.conf:

   zone "example.com" in {
type master;
file "dynamic/example.com/example.com.db";
allow-query { any; };
allow-transfer { external-xfer; };
notify yes;
key-directory "managed-keys/example.com";
inline-signing yes;
auto-dnssec maintain;
};
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: do not stupidly delete ZSK files

[Evan Hunt]

On Wed, Jul 29, 2015 at 05:56:20PM -0700, David Newman wrote:
> 29-Jul-2015 17:18:19.439 general: warning:
> dns_dnssec_keylistfromrdataset: error reading private key file
> example.com/RSASHA256/36114: file not found

Delete that key from the DNSKEY rrset in the zone and reload.

If it's a dynamic zone, freeze it first, then edit the zone file,
delete the key, increase the serial number, and thaw it.

If it's not dynamic, same instructions, but without the freezing
and thawing.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

response case in-sensitivity?

[Mathew Ian Eis]

Howdy BIND,

We’ve been troubleshooting an issue with iOS print discovery using DNS-SD for 
the last several weeks. We made a little bit of a breakthrough this evening 
when we observed in a packet trace that the response case was fully lowercase, 
regardless of the query case. It seems iOS is doing some kind of case sensitive 
comparison between the query and the response, causing DNS-SD to fail when they 
don’t match.

I noticed change 3645, but my reading of the related article suggests that the 
change was actually intended to preserve the case in a query response rather 
than force it to lowercase.

My reading of that article suggests the RFC compliant behavior is to preserve 
the case in the response, is this correct? 
https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clients.html

We’re currently running BIND 9.9.7 (it is likely this issue was introduced when 
we updated from 9.9.4 a while back), so I’m wondering why I am running into 
this. Is there something that I need to turn on to preserve the case in the 
response, or, alternatively, is there something that we have have inadvertently 
changed that would cause BIND to force the response to lowercase?

Thanks in advance,

Mathew Eis
Northern Arizona University
Information Technology Services
mathew@nau.edu
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

do not stupidly delete ZSK files

[David Newman]

I created then loaded then deleted a ZSK, all within an hour, so there's
no backup. Yes, that was a dumb thing to do.

Now when reloading that zone, named.log complains about the missing ZSK:

29-Jul-2015 17:18:19.439 general: warning:
dns_dnssec_keylistfromrdataset: error reading private key file
example.com/RSASHA256/36114: file not found

There are no ZSK files to revoke. Other than disabling DNSSEC for this
zone, how to remove that ZSK so the zone will load clean?

This is bind910-9.10.2P2_5 on 10.1-RELEASE-p16.

Thanks (and don't do as I did)

dn


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Compile Error for Bind 9.9.7P2 on Sparc based Solaris 10

[Bhangui, Sandeep - BLS CTR]

Looked at the config.log fileand see the following messages which to me  
look like linker errorsis that the reason for the compile failure?

Few weeks back I was able to successfully compile 9.9.7 on the same 
machineso not sure what is changed or broken on the system.  This is the 
first time I have encountered this compile error.

Hoping someone can point me in the correct direction.

Thanks
Sandeep


Posting some of the messages from the file.


Undefined   first referenced
symbol in file
setresgid   /var/tmp//ccUAZQW6.o
ld: fatal: symbol referencing errors. No output written to conftest



Undefined   first referenced
symbol in file
kqueue  /var/tmp//cceCnc1l.o
ld: fatal: symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status



Undefined   first referenced
symbol in file
EVP_sha384  /var/tmp//ccgPa8FC.o
ld: fatal: symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status


configure:14317: sparc-sun-solaris2.10-gcc -o conftest -g -O2 -I/usr/include  
-D_XPG4_2 -D__EXTENSIONS__  conftest.c -lgssapi_krb5 -lkrb5 -lk5crypto 
-lcom_err -lresolv >&5
ld: fatal: library -lgssapi_krb5: not found
ld: fatal: library -lk5crypto: not found
ld: fatal: library -lcom_err: not found
ld: fatal: file processing errors. No output written to conftest
collect2: ld returned 1 exit status

configure:14296: checking linking as -lgssapi
configure:14317: sparc-sun-solaris2.10-gcc -o conftest -g -O2 -I/usr/include  
-D_XPG4_2 -D__EXTENSIONS__  conftest.c -lgssapi >&5
ld: fatal: library -lgssapi: not found
ld: fatal: file processing errors. No output written to conftest
collect2: ld returned 1 exit status


From: Bhangui, Sandeep - BLS CTR
Sent: Wednesday, July 29, 2015 9:34 AM
To: 'bind-users@lists.isc.org'
Subject: Compile Error for Bind 9.9.7P2 on Sparc based Solaris 10

Hi

Just found that ISC has released Bind 9.9.7P2 so downloaded that since I had 
issues yesterday compiling P1 on Sparc based Solaris 10 ( M3000)

Get the same error when I run the make with 9.9.7P2 on sparc based Solaris 10 
(M3000) .

Looks like configure runs ok.

Have done this successfully multiple times on Sparc Based Solaris 10 with the 
previous versions of Bind.

Obviously looks like I am missing something hereor has anything changed ?

Any help would be appreciated as I am at a loss.

Thanks
Sandeep


tbl.pl  -o named-symtbl2.c namedtmp2;  done ;  mv namedtmp2 named;  rm -f 
namedtmp0 namedtmp1 namedtmp2 named-symtbl2.c;  fi
Undefined   first referenced
symbol in file
RSA_generate_key_ex ../../lib/dns/libdns.a(opensslrsa_link.o)
DSA_generate_parameters_ex  ../../lib/dns/libdns.a(openssldsa_link.o)
DH_generate_parameters_ex   ../../lib/dns/libdns.a(openssldh_link.o)
ld: fatal: symbol referencing errors. No output written to namedtmp0
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `named'
Current working directory 
/adminfiles/solaris10/Bind997P1/bind-9.9.7-P1/bin/named
*** Error code 1
The following command caused the error:
for i in named rndc dig dnssec tools tests nsupdate  check confgen python 
nulldir; do \
if [ "$i" != "nulldir" -a -d $i ]; then \
echo "making all in `pwd`/$i"; \
(cd $i; make  DESTDIR="" all) || exit 1; \
fi; \
done
make: Fatal error: Command failed for target `subdirs'
Current working directory /adminfiles/solaris10/Bind997P1/bind-9.9.7-P1/bin
*** Error code 1
The following command caused the error:
for i in make unit lib bin doc nulldir; do \
if [ "$i" != "nulldir" -a -d $i ]; then \
echo "making all in `pwd`/$i"; \
(cd $i; make  DESTDIR="" all) || exit 1; \
fi; \
done
make: Fatal error: Command failed for target `subdirs'
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Block propagation for a specific record A

[Grant Taylor]

On 7/29/15 9:35 AM, Grant Taylor wrote:

I don't think you can block propagation like you are wanting to.


You *MIGHT* be able to leverage Response Policy Zone filtering to 
accomplish what you are wanting to do.  But I can't say for sure without 
knowing a LOT more about your infrastructure and the real goal you are 
trying to achieve.



--
Grant. . . .
unix || die

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Block propagation for a specific record A

[Darcy Kevin (FCA)]

If the purpose of the exercise is to identify clients which are querying the 
authoritative nameservers directly without going through an "approved" set of 
recursive resolvers, then this can be accomplished without a "test page": just 
extract from the query logs of the authoritative nameservers the client IPs 
that do not belong to the set of "approved" resolvers.

But, I interpreted the question somewhat differently: what I got from it is 
that they original poster was *expecting* clients to query their authoritative 
nameservers directly and wanted to identify (using the "test page" mechanism) 
clients which were going through intermediate (presumably *unapproved*) 
forwarders. My answer to that would be: you can't really tell, reliably, 
whether a recursive query came through a forwarder or not. Having said that, 
one can mine the query logs and identify source IPs that generate an 
abnormally-high quantity of queries. One could even follow that up with a check 
of whether those IPs are listening on port 53. Another investigative technique 
would be to look at the presence or absence of EDNS0 buffer-size in the queries 
(stub resolvers usually *don't* set buffer size, but DNS software usually 
*does*). These aren't *reliable* methods of finding "unapproved" forwarders, 
but at least they can generate some leads.

Of course, assuming I'm interpreting the original post correctly, I'd question 
why the original poster wants their clients to query the authoritative 
nameservers directly, given the conventional wisdom of separating hosting and 
resolving functions.  I said "question", because this isn't necessarily a *bad* 
thing: these might not be the *published* authoritative nameservers; they might 
be "stealth slaves" in a highly-replicated architecture (such as I favor) that 
maximizes query performance, nameservice resiliency, and enhanced resistance to 
forgery-based attacks and/or cache poisoning. One of the pitfalls of using the 
highly-replicated architecture, in a large enterprise, are the "creative" folks 
who set up unapproved forwarders. Not only do these "rogue" forwarders negate 
some of the availability and security benefits of the highly-replicated 
architecture, but the lack of central configuration control also degrades the 
effectiveness of advanced techniques like sortlisting, D
 NSSEC validation, etc. It's a constant struggle.


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alan Clegg
Sent: Wednesday, July 29, 2015 10:30 AM
To: bind-users@lists.isc.org
Subject: Re: Block propagation for a specific record A

On 7/29/15 4:59 AM, Job wrote:
> Hello,
> 
> for a test page purpuose, we would like to avoid propagation only for a 
> specific record A, example:
> test.domain.com
> 
> We need to test if users set up our DNS server in ethernet configuration, and 
> they display correctly the test page.
> But, if test.domain.com propagate, we are not sure they use our DNS server!
> 
> Is there a way?

Create the A record in a delegated zone that is only available to be queried by 
your recursive servers.

AlanC

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Block propagation for a specific record A

[Grant Taylor]

On 07/29/2015 03:59 AM, Job wrote:

for a test page purpuose, we would like to avoid propagation only for a 
specific record A, example:
test.domain.com


I don't think you can block propagation like you are wanting to.


We need to test if users set up our DNS server in ethernet configuration, and 
they display correctly the test page.
But, if test.domain.com propagate, we are not sure they use our DNS server!


Okay ...


Is there a way?


Here's what I would do.

Configure test.domain.com so that it resolves to a known value for the 
world to see a page that says things are configured incorrectly.


Configure test.domain.com internally so that it resolves to a different 
known value for people to see that says that things are configured 
correctly.  -  You can do this by adding an internal zone that uses Apex 
Overrides to make test.domain.com resolve to a different address.


Link - dotFiles - Apex Override
 - http://dotfiles.tnetconsulting.net/articles/2014/0616/apex-override.html



--
Grant. . . .
unix || die
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Block propagation for a specific record A

[Alan Clegg]

On 7/29/15 4:59 AM, Job wrote:
> Hello,
> 
> for a test page purpuose, we would like to avoid propagation only for a 
> specific record A, example:
> test.domain.com
> 
> We need to test if users set up our DNS server in ethernet configuration, and 
> they display correctly the test page.
> But, if test.domain.com propagate, we are not sure they use our DNS server!
> 
> Is there a way?

Create the A record in a delegated zone that is only available to be
queried by your recursive servers.

AlanC



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Compile Error for Bind 9.9.7P2 on Sparc based Solaris 10

[Bhangui, Sandeep - BLS CTR]

Hi

Just found that ISC has released Bind 9.9.7P2 so downloaded that since I had 
issues yesterday compiling P1 on Sparc based Solaris 10 ( M3000)

Get the same error when I run the make with 9.9.7P2 on sparc based Solaris 10 
(M3000) .

Looks like configure runs ok.

Have done this successfully multiple times on Sparc Based Solaris 10 with the 
previous versions of Bind.

Obviously looks like I am missing something hereor has anything changed ?

Any help would be appreciated as I am at a loss.

Thanks
Sandeep


tbl.pl  -o named-symtbl2.c namedtmp2;  done ;  mv namedtmp2 named;  rm -f 
namedtmp0 namedtmp1 namedtmp2 named-symtbl2.c;  fi
Undefined   first referenced
symbol in file
RSA_generate_key_ex ../../lib/dns/libdns.a(opensslrsa_link.o)
DSA_generate_parameters_ex  ../../lib/dns/libdns.a(openssldsa_link.o)
DH_generate_parameters_ex   ../../lib/dns/libdns.a(openssldh_link.o)
ld: fatal: symbol referencing errors. No output written to namedtmp0
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `named'
Current working directory 
/adminfiles/solaris10/Bind997P1/bind-9.9.7-P1/bin/named
*** Error code 1
The following command caused the error:
for i in named rndc dig dnssec tools tests nsupdate  check confgen python 
nulldir; do \
if [ "$i" != "nulldir" -a -d $i ]; then \
echo "making all in `pwd`/$i"; \
(cd $i; make  DESTDIR="" all) || exit 1; \
fi; \
done
make: Fatal error: Command failed for target `subdirs'
Current working directory /adminfiles/solaris10/Bind997P1/bind-9.9.7-P1/bin
*** Error code 1
The following command caused the error:
for i in make unit lib bin doc nulldir; do \
if [ "$i" != "nulldir" -a -d $i ]; then \
echo "making all in `pwd`/$i"; \
(cd $i; make  DESTDIR="" all) || exit 1; \
fi; \
done
make: Fatal error: Command failed for target `subdirs'
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS format error

[Tony Finch]

Mukund Sivaraman  wrote:
>
> Mark pointed out on our internal bug ticket that RFC 2308 section 3
> requires "no data" replies from signed zones to have an SOA RR in the
> authority section.

Aha! Thanks for pointing that out :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Biscay: Northerly or northwesterly, veering northeasterly in south, 4 or 5.
Slight or moderate. Occasional rain in south. Good, occasionally moderate in
south.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS format error

[Mukund Sivaraman]

Hi Tony, Yang

On Tue, Jul 28, 2015 at 10:41:49PM +0100, Tony Finch wrote:
> However the weirdness in the NSEC3 record is not what is upsetting BIND,
> and it might be a bug. A noerror response with just NSEC3 and RRSIG(NSEC3)
> in the authority section should (I think) be treated as a type 3 nodata
> response (see RFC 2308). However BIND requires type 3 nodata responses to
> have completely empty authority sections. BIND will only recognise type 1
> or type 2 nodata responses (with SOA records in the authority section)
> from signed zones.

Mark pointed out on our internal bug ticket that RFC 2308 section 3
requires "no data" replies from signed zones to have an SOA RR in the
authority section.

Mukund


pgpGbmLx5vWnF.pgp
Description: PGP signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Block propagation for a specific record A

[Job]

Hello,

for a test page purpuose, we would like to avoid propagation only for a 
specific record A, example:
test.domain.com

We need to test if users set up our DNS server in ethernet configuration, and 
they display correctly the test page.
But, if test.domain.com propagate, we are not sure they use our DNS server!

Is there a way?

Thank you!
Francesco
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS format error

[Mukund Sivaraman]

On Wed, Jul 29, 2015 at 08:13:38AM +0200, Matus UHLAR - fantomas wrote:
> On 29.07.15 03:06, Yang Yu wrote:
> >I configured bind to forward queries to 8.8.8.8
> 
> do you have any reason to do this?
> BIND can resolve properly itself, it does not need to forward queries to
> anyone unless you are firewalled (in such case, do you really need BIND?)
> without forwarding you apparently won't get this error...

The formerr occurs during message processing during normal resolution
because of the peculiar reply in this case from the nameserver for
www.vip.icann.org. We will look into it.

Mukund


pgpjof_aPPrq2.pgp
Description: PGP signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users