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

[Darcy Kevin (FCA)]

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, then you can 
just ignore how the records are represented in the zone file on the master 
and/or slave. Nothing to see here, move along.

Do you have access to some sort of packet capture program (e.g. 
wireshark/tcpdump/snoop) and at least some rudimentary skills in using such a 
tool? Such a tool and the knowledge to use it, will serve you well if you 
intend to progress as a DNS administrator.


- Kevin


P.S. I trimmed the remainder of the message thread, since you responded to a 
digest and thus included a bunch of messages which are unrelated to the topic 
at hand.

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Vaughan
Sent: Monday, January 05, 2015 11:04 PM
To: 'bind-users@lists.isc.org'
Subject: RE: bind-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue 

Yes,

I have read that part of the FAQ, which concerns people asking whether they 
need to add escape characters manually in the DMARC record. 

I do not add these myself. As shown by my examples below, the entry in the 
master zone is free of any escape characters. However, when an update is 
triggered, the escape characters are being added to the entry on the slave zone 
automatically. Why is this happening and how do I stop it?

Chris Vaughan | Communications Officer, ICT Land and Property Information | 
Level 5, 1 Prince Albert Road Queens Square NSW 2000
e: chris.vaug...@lpi.nsw.gov.au | t: 02 92286884 | m: 0401 148061 | f: 02 
92231271 | http://www.services.nsw.gov.au I http://www.lpi.nsw.gov.au


___
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

DNS weirdness

[The Doctor]

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 file

//Use with the following in named.conf, adjusting the allow list as needed:
key "rndc-key" {
  algorithm hmac-md5;
  secret "7ZbGK94NdSa2WACxx72W1w==";
};

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; };
};




// generated by named-bootconf.pl

options {
directory "/etc/namedb";
pid-file "/var/run/named.pid";
dump-file "/etc/namedb/named.core";
max-ncache-ttl 86400;
recursive-clients 100;
reserved-sockets 128;
tcp-clients 40;
tcp-listen-queue 14;
zone-statistics yes;
forwarders { 208.67.222.222; 208.67.220.220; };
blackhole {
65.94.172.87;
67.68.204.41;
74.15.184.13;
65.94.173.208;
};
allow-transfer {
204.209.81.1;
204.209.81.8;
204.209.81.14;
};
allow-notify {
204.209.81.1;
204.209.81.8;
204.209.81.14;
};
also-notify {
204.209.81.1 port 53;
204.209.81.8 port 53;
204.209.81.14 port 53;
};
/*
 * If there is a firewall between you and nameservers you want
 * to talk to, you might need to uncomment the query-source
 * directive below.  Previous versions of BIND always asked   
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Birthday 29 Jan 1969, REdhill Surrey, England, UK

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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 weirdness

[Darcy Kevin (FCA)]

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.

- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of The Doctor
Sent: Tuesday, January 06, 2015 1:50 PM
To: comp-protocols-dns-b...@isc.org
Subject: 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 file

//Use with the following in named.conf, adjusting the allow list as needed:
key "rndc-key" {
  algorithm hmac-md5;
  secret "7ZbGK94NdSa2WACxx72W1w=="; };

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; }; };




// generated by named-bootconf.pl

options {
directory "/etc/namedb";
pid-file "/var/run/named.pid";
dump-file "/etc/namedb/named.core";
max-ncache-ttl 86400;
recursive-clients 100;
reserved-sockets 128;
tcp-clients 40;
tcp-listen-queue 14;
zone-statistics yes;
forwarders { 208.67.222.222; 208.67.220.220; };
blackhole {
65.94.172.87;
67.68.204.41;
74.15.184.13;
65.94.173.208;
};
allow-transfer {
204.209.81.1;
204.209.81.8;
204.209.81.14;
};
allow-notify {
204.209.81.1;
204.209.81.8;
204.209.81.14;
};
also-notify {
204.209.81.1 port 53;
204.209.81.8 port 53;
204.209.81.14 port 53;
};
/*
 * If there is a firewall between you and nameservers you want
 * to talk to, you might need to uncomment the query-source
 * directive below.  Previous versions of BIND always asked   
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware 
AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism 
Birthday 29 Jan 1969, REdhill Surrey, England, UK

--
This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

___
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
___
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

Odd response from upstream DNS servers

[Levi Pederson]

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 response goes back to my
DNS server)
3.  I'm then supposed to send that response back to the client to use for
requests

However I can see the request come back to my server only to be rejected as
FORMERR  and DNS format error badresp:1

Can anyone help me understand where the error in this issue exists?

I have wire sharked and can see the response packet come back to my servers
outside interface and the rejection

Thank you,

*Levi Pederson*
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipeder...@mankatonetworks.net
___
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 weirdness

[Marco Davids (SIDN)]

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 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: Odd response from upstream DNS servers

[Evan Hunt]

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 if you told us what query you were
trying to resolve, and what version of BIND you're running.

-- 
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

Re: Odd response from upstream DNS servers

[Warren Kumari]

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 response.  We'd be
> better equipped to diagnose the problem if you told us what query you were
> trying to resolve, and what version of BIND you're running.

... and if you send the "have wire sharked and can see the response
packet come back to my servers outside interface and the rejection"
bit.

W

>
> --
> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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: Odd response from upstream DNS servers

[Levi Pederson]

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 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 if you told us what query you
> were
> > trying to resolve, and what version of BIND you're running.
>
> ... and if you send the "have wire sharked and can see the response
> packet come back to my servers outside interface and the rejection"
> bit.
>
> W
>
> >
> > --
> > 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
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
___
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: Odd response from upstream DNS servers

[Levi Pederson]

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-Dec-2014 23:11:21.417 fctx 0x7f9d7f856010(Domain-request/NAPTR'): start
16-Dec-2014 23:11:21.417 fctx 0x7f9d7f856010(Domain-request/NAPTR'): try
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
cancelqueries
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
getaddresses
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'): query
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx
0x7f9d7f856010(Domain-request/NAPTR)): send
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx
0x7f9d7f856010(Domain-request/NAPTR)): sent
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx
0x7f9d7f856010(Domain-request/NAPTR)): udpconnected
16-Dec-2014 23:11:21.419 resquery 0x7f9d7f85d010 (fctx
0x7f9d7f856010(Domain-request/NAPTR)): senddone
16-Dec-2014 23:11:21.489 resquery 0x7f9d7f85d010 (fctx
0x7f9d7f856010(Domain-request/NAPTR)): response
;Domain-request.IN NAPTR

UPSTREAM RESPONSES

UPSTREAM-RESPONSE 86400 IN A Correct-IP#1
UPSTREAM-RESPONSE 86400 IN A Correct-IP#2
UPSTREAM-RESPONSE 86285 IN A Correct-IP#3
16-Dec-2014 23:11:21.490 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
noanswer_response
16-Dec-2014 23:11:21.490 log_ns_ttl: fctx 0x7f9d7f856010:
noanswer_response: Domain-request (in 'domain-name'?): 1 86285
16-Dec-2014 23:11:21.490 fctx 0x7f9d7f856010: trimming ttl of
domain-name/NS for Domain-request/NAPTR: 86400 -> 86285
16-Dec-2014 23:11:21.490 DNS format error from upstreamServer#53 resolving
Domain-request/NAPTR for client CLIENT-IP#15000: non-improving referral
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
cancelquery
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): add_bad
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): try
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
cancelqueries
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
getaddresses
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): no
addresses
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): done
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
stopeverything
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
cancelqueries
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
sendevents
16-Dec-2014 23:11:21.492 fetch 0x7f9d85d591d0 (fctx
0x7f9d7f856010(Domain-request/NAPTR)): destroyfetch
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
shutdown
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
doshutdown
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
stopeverything
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'):
cancelqueries
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): unlink
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): destroy



Default.LOG

17-Dec-2014 00:07:38.205 query-errors: debug 2: fetch completed at
resolver.c:3073 for domain-name/A in 0.071177: failure/success
[domain:domain-name,referral:0,restart:2,qrysent:
1,timeout:0,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]


While I know the Time stamps are different the same thing happens with each
request.  Now onto the wireshark parse.

*Levi Pederson*
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipeder...@mankatonetworks.net


On Tue, Jan 6, 2015 at 1: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 response.  We'd be
> better equipped to diagnose the problem if you told us what query you were
> trying to resolve, and what version of BIND you're running.
>
> --
> 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

RE: Odd response from upstream DNS servers

[Adrian Beaudin]

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, Inc.
o: +1.650.587.1513
adrian.beau...@nominum.com



From: bind-users-boun...@lists.isc.org [bind-users-boun...@lists.isc.org] on 
behalf of Levi Pederson [levipeder...@mankatonetworks.net]
Sent: Tuesday, January 06, 2015 3:25 PM
To: Evan Hunt
Cc: bind-users@lists.isc.org
Subject: 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-Dec-2014 23:11:21.417 fctx 0x7f9d7f856010(Domain-request/NAPTR'): start
16-Dec-2014 23:11:21.417 fctx 0x7f9d7f856010(Domain-request/NAPTR'): try
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
cancelqueries
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
getaddresses
16-Dec-2014 23:11:21.418 fctx 0x7f9d7f856010(Domain-request/NAPTR'): query
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx 
0x7f9d7f856010(Domain-request/NAPTR)): send
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx 
0x7f9d7f856010(Domain-request/NAPTR)): sent
16-Dec-2014 23:11:21.418 resquery 0x7f9d7f85d010 (fctx 
0x7f9d7f856010(Domain-request/NAPTR)): udpconnected
16-Dec-2014 23:11:21.419 resquery 0x7f9d7f85d010 (fctx 
0x7f9d7f856010(Domain-request/NAPTR)): senddone
16-Dec-2014 23:11:21.489 resquery 0x7f9d7f85d010 (fctx 
0x7f9d7f856010(Domain-request/NAPTR)): response
;Domain-request.IN NAPTR

UPSTREAM RESPONSES

UPSTREAM-RESPONSE 86400 IN A Correct-IP#1
UPSTREAM-RESPONSE 86400 IN A Correct-IP#2
UPSTREAM-RESPONSE 86285 IN A Correct-IP#3
16-Dec-2014 23:11:21.490 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
noanswer_response
16-Dec-2014 23:11:21.490 log_ns_ttl: fctx 0x7f9d7f856010: noanswer_response: 
Domain-request (in 'domain-name'?): 1 86285
16-Dec-2014 23:11:21.490 fctx 0x7f9d7f856010: trimming ttl of domain-name/NS 
for Domain-request/NAPTR: 86400 -> 86285
16-Dec-2014 23:11:21.490 DNS format error from upstreamServer#53 resolving 
Domain-request/NAPTR for client CLIENT-IP#15000: non-improving referral
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): cancelquery
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): add_bad
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): try
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
cancelqueries
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
getaddresses
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): no 
addresses
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): done
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
stopeverything
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
cancelqueries
16-Dec-2014 23:11:21.491 fctx 0x7f9d7f856010(Domain-request/NAPTR'): sendevents
16-Dec-2014 23:11:21.492 fetch 0x7f9d85d591d0 (fctx 
0x7f9d7f856010(Domain-request/NAPTR)): destroyfetch
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): shutdown
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): doshutdown
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
stopeverything
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): 
cancelqueries
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): unlink
16-Dec-2014 23:11:21.492 fctx 0x7f9d7f856010(Domain-request/NAPTR'): destroy



Default.LOG

17-Dec-2014 00:07:38.205 query-errors: debug 2: fetch completed at 
resolver.c:3073 for domain-name/A in 0.071177: failure/success 
[domain:domain-name,referral:0,restart:2,qrysent:1,timeout:0,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]


While I know the Time stamps are different the same thing happens with each 
request.  Now onto the wireshark parse.

Levi Pederson
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipeder...@mankatonetworks.net
[http://www.mankatonetworks.com/images/mn_logo_email.png]

On Tue, Jan 6, 2015 at 1:48 PM, Evan Hunt mailto:e...@isc.org>> 
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 response.  We'd be
better equipped to diagnose the problem if you told us what query you were
trying to resolve, and what version of BIND you're running.

--

Re: Odd response from upstream DNS servers

[Levi Pederson]

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. TimeSourceDestination
Protocol Length Info
838 06:11:21.064388 CLIENT LOCAL-DNS-SERVER  DNS
 114Standard query 0x0479  NAPTR DOMAIN-NAME-REQUEST

Frame 838: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Cisco_b9:31:c0 (1c:e6:c7:b9:31:c0), Dst: Vmware_a0:18:f3
(00:50:56:a0:18:f3)
Internet Protocol Version 4, Src: CLIENT (CLIENT), Dst: LOCAL-DNS-SERVER
(LOCAL-DNS-SERVER)
User Datagram Protocol, Src Port: hydap (15000), Dst Port: domain (53)
Domain Name System (query)
[Response In: 3400]
Transaction ID: 0x0479
Flags: 0x0100 Standard query
0...    = Response: Message is a query
.000 0...   = Opcode: Standard query (0)
 ..0.   = Truncated: Message is not truncated
 ...1   = Recursion desired: Do query recursively
  .0..  = Z: reserved (0)
  ...0  = Non-authenticated data: Unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
DOMAIN-NAME-REQUEST: type NAPTR, class IN

No. TimeSourceDestination
Protocol Length Info
839 06:11:21.066859 LOCAL-DNS-SERVER  UPSTREAM-DNS-SERVER
  DNS  125Standard query 0xb83c  NAPTR DOMAIN-NAME-REQUEST

Frame 839: 125 bytes on wire (1000 bits), 125 bytes captured (1000 bits)
Ethernet II, Src: Vmware_a0:18:f3 (00:50:56:a0:18:f3), Dst: Cisco_b9:31:c0
(1c:e6:c7:b9:31:c0)
Internet Protocol Version 4, Src: LOCAL-DNS-SERVER (LOCAL-DNS-SERVER), Dst:
UPSTREAM-DNS-SERVER (UPSTREAM-DNS-SERVER)
User Datagram Protocol, Src Port: 23175 (23175), Dst Port: domain (53)
Domain Name System (query)
[Response In: 840]
Transaction ID: 0xb83c
Flags: 0x0110 Standard query
0...    = Response: Message is a query
.000 0...   = Opcode: Standard query (0)
 ..0.   = Truncated: Message is not truncated
 ...1   = Recursion desired: Do query recursively
  .0..  = Z: reserved (0)
  ...1  = Non-authenticated data: Acceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
DOMAIN-NAME-REQUEST: type NAPTR, class IN
Additional records
: type OPT

No. TimeSourceDestination
Protocol Length Info
840 06:11:21.154523 UPSTREAM-DNS-SERVER LOCAL-DNS-SERVER
   DNS  245Standard query response 0xb83c

Frame 840: 245 bytes on wire (1960 bits), 245 bytes captured (1960 bits)
Ethernet II, Src: Cisco_b9:31:c0 (1c:e6:c7:b9:31:c0), Dst: Vmware_a0:18:f3
(00:50:56:a0:18:f3)
Internet Protocol Version 4, Src: UPSTREAM-DNS-SERVER
(UPSTREAM-DNS-SERVER), Dst: LOCAL-DNS-SERVER (LOCAL-DNS-SERVER)
User Datagram Protocol, Src Port: domain (53), Dst Port: 23175 (23175)
Domain Name System (response)
[Request In: 839]
[Time: 0.087664000 seconds]
Transaction ID: 0xb83c
Flags: 0x8100 Standard query response, No error
1...    = Response: Message is a response
.000 0...   = Opcode: Standard query (0)
 .0..   = Authoritative: Server is not an authority for
domain
 ..0.   = Truncated: Message is not truncated
 ...1   = Recursion desired: Do query recursively
  0...  = Recursion available: Server can't do
recursive queries
  .0..  = Z: reserved (0)
  ..0.  = Answer authenticated: Answer/authority
portion was not authenticated by the server
  ...0  = Non-authenticated data: Unacceptable
    = Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 3
Additional RRs: 4
Queries
DOMAIN-NAME-REQUEST: type NAPTR, class IN
Authoritative nameservers
CORRECT-DNS-SERVER#1: type NS, class IN, ns CORRECT-DNS-SERVER#1
CORRECT-DNS-SERVER#2: type NS, class IN, ns CORRECT-DNS-SERVER#2
CORRECT-DNS-SERVER#3: type NS, class IN, ns CORRECT-DNS-SERVER#3
Additional records
CORRECT-DNS-SERVER#1: type A, class IN, addr IP1
CORRECT-DNS-SERVER#2: type A, class IN, addr IP2
CORRECT-DNS-SERVER#3: type A, class IN, addr IP3
: type OPT

No. TimeSourceDestination
Protocol Length Info
841 06:11:21.157804 LOCAL-DNS-SERVER  CLIENT DNS
 114Standard query response 0x0479 Server failure

Frame 841: 114 bytes on wire (912 bits), 114 bytes captured (912 bits)
Ethernet II, Src: Vmware_a0:18:f3 (00:50:56:a0:18:f3), D

Re: Odd response from upstream DNS servers

[Evan Hunt]

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..   = Authoritative: Server is not an authority for
> domain

Bad delegation, I guess.  The "authoritative" server says it isn't.

--
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

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

[Anne Bennett]

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 at
communication with known external bad hosts.  I start with a
fairly extensive whitelist, to avoid "lying" about any of my own
hosts, and to give truthful answers for patch sites, so that my
users can patch their systems even when otherwise quarantined.

The masters for my RPZs do not themselves use the zones
for policy (nor do they recurse on queries).  However the
nameservers that do recursive resolution for my network are
slaves for those RPZs, and *do* use them for policy.

My set-up works, but sporadically - it's as though the RPZs wink
in and out of use for no apparent reason, even when I'm not
changing the data.  At one point while testing last December,
my by-client-IP test quarantine rule just stopped matching
(based on no logged hits, and no redirection of my queries
from the quarantined host).  Only a restart of named on the
resolver brought the quarantine back, but then the whitelist
worked only partially.

I don't know what to make of this; it looks as though the
technology is several years old, and my experience with ISC
bind is usually excellent.  Has anyone else encountered this
type of flakiness?

If not, any advice about how to debug this?


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
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: Odd response from upstream DNS servers

[Levi Pederson]

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.  I'm going to continue in that skein
until I have found an answer.

case closed : Thank you to all for your help and additions and your time.

Thank you,


*Levi Pederson*
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipeder...@mankatonetworks.net


On Tue, Jan 6, 2015 at 4:44 PM, Evan Hunt  wrote:

> 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..   = Authoritative: Server is not an authority
> for
> > domain
>
> Bad delegation, I guess.  The "authoritative" server says it isn't.
>
> --
> 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

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

[John Miller]

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 out by giving us your bind version and your
response-policy {} config.  Also print out the exact rules (one or two
examples should suffice) you're using for client quarantining --
that'll help narrow things down.  Also, how are you publishing to your
client quarantine zones?  Presumably you're using some sort of DDNS
publishing that gets triggered when a client does something
suspicious.

John
-- 
John Miller
Systems Engineer
Brandeis University
johnm...@brandeis.edu


On Tue, Jan 6, 2015 at 5:52 PM, Anne Bennett  wrote:
> I'm playing with RPZ with a view to both quarantining internal
> compromised or vulnerable hosts, and capturing attempts at
> communication with known external bad hosts.  I start with a
> fairly extensive whitelist, to avoid "lying" about any of my own
> hosts, and to give truthful answers for patch sites, so that my
> users can patch their systems even when otherwise quarantined.
>
> The masters for my RPZs do not themselves use the zones
> for policy (nor do they recurse on queries).  However the
> nameservers that do recursive resolution for my network are
> slaves for those RPZs, and *do* use them for policy.
>
> My set-up works, but sporadically - it's as though the RPZs wink
> in and out of use for no apparent reason, even when I'm not
> changing the data.  At one point while testing last December,
> my by-client-IP test quarantine rule just stopped matching
> (based on no logged hits, and no redirection of my queries
> from the quarantined host).  Only a restart of named on the
> resolver brought the quarantine back, but then the whitelist
> worked only partially.
>
> I don't know what to make of this; it looks as though the
> technology is several years old, and my experience with ISC
> bind is usually excellent.  Has anyone else encountered this
> type of flakiness?
>
> If not, any advice about how to debug this?
___
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: still stuck with named memory leak

[Mukund Sivaraman]

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 reports sent in by other users, so if there is any real problem
lurking, it is evading us.

As there are 2-3 such reports, we want to be certain that there is no
actual leak or excessive memory usage.

Mukund

On Wed, Dec 24, 2014 at 05:59:41AM +0530, Mukund Sivaraman wrote:
> Hi Len
> 
> On Tue, Dec 23, 2014 at 03:02:49PM -0600, lcon...@go2france.com wrote:
> > sent data to a ISC.org guy, no response.
> 
> Is this about the config file that you sent me? I had asked you to send
> me dumps over time of the named statistics that are available via HTTP,
> as the named process grows. See the "statistics-channels" documentation
> in the manual. You can use curl or wget to dump them to a file.
> 
> We are very curious about these reports, but so far we do not have
> enough information that points at any leaks. Even this week we have been
> working with a different BIND user who, along with you, has reported
> memory growth issues, but we haven't been able to find any leaks from
> the given data.
> 
> > filled in the form on isc.org site, got a canned response:  "try bind user
> > list   pay for support"
> > 
> > any suggestions?
> 
> The best way to report BIND bugs as a tracked ticket is to email
> . This is the developers' bug tracker. Another way
> is to discuss this on the BIND lists, which you have done.
> 
> Please do this now:
> 
> 1. Enable the "statistics-channels" of named so that you are able to
> dump XML statistics using HTTP and test that you are able to.
> 
> 2. When you notice that named has started growing conspicuously and you
> think it's process size is something it should not be, note down its
> virtual process size (VSZ) and resident set size (RSS) fields which you
> can get through ps, along with a timestamp.
> 
> 3. Along with noting the VSZ and RSS sizes, also dump the corresponding
> XML statistics using HTTP to a file.
> 
> Please send these stats to us, either via the 
> tracker, or this mailing list.
> 
>   Mukund


pgp5AXM_zDW1s.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

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

[Michael McNally]

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 key ID
   45AC7857189CDBC5, was created in 2013 with an expiration
   date of 31 January, 2015, a date that is fast approaching.

   It is being replaced by a new key with key ID
   6FA6EBC9911A4C02, and an expiration date of 31 January, 2017.

Until the expiration of the 2013 key, ISC will sign code releases
with both keys.  This includes the development releases released
today (BIND 9.9.7b1 and BIND 9.10.2b1.)  You may therefore encounter
a message from PGP or GPG when verifying your download if you do
not have both keys in your keyring.  You can disregard such messages
as long as PGP or GPG confirms a valid signature with at least one
of the keys.

Both keys are available from the ISC website:

  https://www.isc.org/downloads/software-support-policy/openpgp-key/

And if you need instructions on how to verify a download using PGP
or GPG, a brief summary can be found in the ISC Knowledge Base:

  https://kb.isc.org/article/AA-01225

Given the recent security incident with the ISC web site, some will
naturally ask whether the retirement of the old key was prompted
by security concerns.  The answer to that is no, we have no suspicion
that the old key was compromised in any way; the key change is 
motivated solely by the January 31, 2015 expiration date that was
set when the key was generated years ago.  We are choosing this
time to issue the replacement to allow an interim period during
which people have time to retrieve the new key.

Some parties may also have reservations about trusting a key
downloaded from a site that was recently compromised.  If you you
prefer you can download the key from the public keyserver
https://pgp.mit.edu

Please take note that after 31 January, 2015 new releases will no
longer be signed using the expiring key (key id 45AC7857189CDBC5)
and so if you use PGP or GPG to check the integrity of your downloads
you should import the new key before that occurs.

Michael McNally
ISC Support
___
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 weirdness

[The Doctor]

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. This won't suffice for a busy server.
>

Well so far so good on the servers here.

Still the primary locked tongiht, ran on backup and the
secondary displayed the same symptoms save
that is was able to find all the stuff on the local DNS
>

>   - Kevin
>
>-Original Message-
>From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc=
>.org] On Behalf Of The Doctor
>Sent: Tuesday, January 06, 2015 1:50 PM
>To: comp-protocols-dns-b...@isc.org
>Subject: 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 file
>
>//Use with the following in named.conf, adjusting the allow list as needed:
>key "rndc-key" {
>  algorithm hmac-md5;
>  secret "7ZbGK94NdSa2WACxx72W1w=3D=3D"; };
>
>controls {
>  inet 127.0.0.1 port 953
>  allow { 127.0.0.1; } keys { "rndc-key"; }; };
>
>
>
>
>// generated by named-bootconf.pl
>
>options {
>directory "/etc/namedb";
>pid-file "/var/run/named.pid";
>dump-file "/etc/namedb/named.core";
>max-ncache-ttl 86400;
>recursive-clients 100;
>reserved-sockets 128;
>tcp-clients 40;
>tcp-listen-queue 14;
>zone-statistics yes;
>forwarders { 208.67.222.222; 208.67.220.220; };
>blackhole {
>65.94.172.87;
>67.68.204.41;
>74.15.184.13;
>65.94.173.208;
>};
>allow-transfer {
>204.209.81.1;
>204.209.81.8;
>204.209.81.14;
>};
>allow-notify {
>204.209.81.1;
>204.209.81.8;
>204.209.81.14;
>};
>also-notify {
>204.209.81.1 port 53;
>204.209.81.8 port 53;
>204.209.81.14 port 53;
>};
>/*
> * If there is a firewall between you and nameservers you want
> * to talk to, you might need to uncomment the query-source
> * directive below.  Previous versions of BIND always asked  =20
>--
>Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.=
>ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChris=
>t rising!=20
>http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism Bir=
>thday 29 Jan 1969, REdhill Surrey, England, UK
>
>--
>This message has been scanned for viruses and dangerous content by MailScan=
>ner, and is believed to be clean.
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri=
>be from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users


-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Birthday 29 Jan 1969, REdhill Surrey, England, UK
___
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