Re: DNS weirdness

In article , Darcy Kevin (FCA) wrote: >This nameserver is forwarding to 208.67.222.222 and 208.67.220.220. Are tho= >se valid and working? > OPenDNS and it looks like they kicked the account. >Also, a bunch of your tunables are set really low -- particularly, recursiv= >e-clients set to 100. Th

ISC has issued a new code signing key. Previous key expires 31 January

Happy New Year to the BIND community, Beginning with the start of 2015, ISC is introducing a new PGP signing key which will be used to verify the authenticity of BIND and DHCP source downloaded from ISC. This replaces the current key, which is expiring. The old key for codes...@isc.org, with

Re: still stuck with named memory leak

Hi Len Have you had a chance to make statistics dumps for this memory usage issue? We'd appreciate it if you can follow up on your report by sending the statistics output when the process size has grown to an abnormal size. So far, we haven't been able to find evidence of high memory usage from r

Re: How reliable is RPZ in production? I'm seeing flakiness in testing.

Hi Anne, We've been using RPZ in production for over six months, and haven't had any serious issues. We haven't encountered this specific type of flakiness, but then again, it's likely our configs and bind versions aren't the same either: we do our quarantining at layer 2. You might start things

Re: Odd response from upstream DNS servers

All, I understand this would be easier if it were not obfuscated. But alas that is not something that can be done. Thank you to all who have responded. A lot of the information I'm receiving is indicating something on the authority level. Who has it, Who is supposed to have it, and the like.

How reliable is RPZ in production? I'm seeing flakiness in testing.

Happy New Year, folks. I posted last December to dnsfirewalls, but I'm told that RPZ is no longer particularly new, and I'd be more likely to get feedback here. So here goes... I'm playing with RPZ with a view to both quarantining internal compromised or vulnerable hosts, and capturing attempts

Re: Odd response from upstream DNS servers

This would really be a lot easier if it were not anonymized. However... On Tue, Jan 06, 2015 at 02:43:30PM -0600, Levi Pederson wrote: > Packet 840 Upstream-NS ---> Local-NS [...] > Frame 840: 245 bytes on wire (1960 bits), 245 bytes captured (1960 bits) [...] > .0.. = Auth

Re: Odd response from upstream DNS servers

All, Bind is version : root@ns1:~# named -v BIND 9.8.4-rpz2+rl005.12-P1 And here is the Packet Disection Packet 838 Client ---> Local Name Server Packet 839 Local-NS ---> Upstream NS Packet 840 Upstream-NS ---> Local-NS Packet 841 Local-NS ---> Client No. TimeSource

RE: Odd response from upstream DNS servers

Hi Levi, Are you able to use dig to make sure that the server is responding properly? fwiw, I have seen mobile/voice equipment in the past that had oddly written dns resolvers - some caused weird issues even with valid responses. -a Adrian Beaudin Principal Architect, Special Projects Nominum

Re: Odd response from upstream DNS servers

Alrighty, There could be a lot of sensitive information in the wire shark and I'm looking at how to parse that now. Currently here is the RESPONSE.log and default.log information RESPONSE.log 16-Dec-2014 23:11:21.417 fetch 0x7f9d85d591d0 (fctx 0x7f9d7f856010(Domain-request/NAPTR)): created 16-D

Re: Odd response from upstream DNS servers

I'll see about getting that information colluded and sent. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Tue, Jan 6, 2015 at 1:56 PM, Warren Kumari wrote: > On Tue, Jan 6, 2015 at 2:48 PM, Evan Hunt wrote: > > On

Re: Odd response from upstream DNS servers

On Tue, Jan 6, 2015 at 2:48 PM, Evan Hunt wrote: > On Tue, Jan 06, 2015 at 01:03:10PM -0600, Levi Pederson wrote: >> However I can see the request come back to my server only to be rejected as >> FORMERR and DNS format error badresp:1 > > It looks like the upstream server send a badly formatted r

Re: Odd response from upstream DNS servers

On Tue, Jan 06, 2015 at 01:03:10PM -0600, Levi Pederson wrote: > However I can see the request come back to my server only to be rejected as > FORMERR and DNS format error badresp:1 It looks like the upstream server send a badly formatted response. We'd be better equipped to diagnose the problem

Re: DNS weirdness

Darcy Kevin (FCA) schreef op 06-01-15 om 19:56: > This nameserver is forwarding to 208.67.222.222 and 208.67.220.220. Are those > valid and working? OpenDNS, right? -- Marco smime.p7s Description: S/MIME-cryptografische ondertekening ___ Please vi

Odd response from upstream DNS servers

All, I have an ODD issue with a request to an upstream DNS server 1. I receive the Downstream request and can't fill it locally so I send request up to upstream server 2. Upstream receives it and does it's thing and sends back a response with the proper servers for the client to query (this res

RE: DNS weirdness

This nameserver is forwarding to 208.67.222.222 and 208.67.220.220. Are those valid and working? Also, a bunch of your tunables are set really low -- particularly, recursive-clients set to 100. This won't suffice for a busy server.

DNS weirdness

Help needed. This morning my primary DNS server locked. No worries, the backup will kick in. Wrong !! The Secondary DNS server cannot resolve properly unless the 'real' primary is working. All right, why is the secondary server behaving this way? Satrt of secondary DNS server named.conf fil

RE: bind-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue

I think you need to understand that what's in the zone file is of little importance -- what matters is how the data is being sent "over the wire" (as they say). The consumers of DMARC (mail servers) only care about the data that gets sent to them over the wire. If it's correct over-the-wire, the