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 th
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-a
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 rr
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
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 doin
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
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
fi
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
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 t
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, an
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
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 mu
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
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 nodat
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
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 f
16 matches
Mail list logo
