Diagnostic help

[Bill Christensen]

Hi folks,

Something got sideways on one of my DNS servers, and I would appreciate 
some help in figuring out what's going on.


I'm running BIND 9.10.1.  This server is authoritative master for a 
number of domains.


First off, I may have the allow-query set incorrectly.  Currently I have:

acl query-permit {
(range of IP address on the local LAN which are allowed to use this 
server as their query server)

};

acl recursive-permit {
(range of IP address on the local LAN which are allowed to use this 
server for recursive queries)

};

acl transfer-permit {
(IP addresses of a couple other name servers allowed to do 
transfers with this one)

};

and at the beginning of the options  section:

allow-recursion { recursive-permit; };
 allow-transfer { transfer-permit; };
// allow-query { query-permit; };

Allow-query is commented out, which I assume will allow anyone to query 
this server for the domains for which it has master or slave records, 
but does not allow the general public to do recursive queries or queries 
on domains not hosted here.


Let me know if I've got that right, or how to correct it if I don't.

If this part is correct I'll continue the questioning.

Thanks!



___
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: Diagnostic help

[Ben Croswell]

The default for allow query is local host local nets.  Basically the server
itself and directly connected networks
On Sep 29, 2014 8:03 PM, "Bill Christensen" 
wrote:

>  Hi folks,
>
> Something got sideways on one of my DNS servers, and I would appreciate
> some help in figuring out what's going on.
>
> I'm running BIND 9.10.1.  This server is authoritative master for a number
> of domains.
>
> First off, I may have the allow-query set incorrectly.  Currently I have:
>
> acl query-permit {
> (range of IP address on the local LAN which are allowed to use this
> server as their query server)
> };
>
> acl recursive-permit {
> (range of IP address on the local LAN which are allowed to use this
> server for recursive queries)
> };
>
> acl transfer-permit {
> (IP addresses of a couple other name servers allowed to do transfers
> with this one)
> };
>
> and at the beginning of the options  section:
>
> allow-recursion { recursive-permit; };
>  allow-transfer { transfer-permit; };
> // allow-query { query-permit; };
>
> Allow-query is commented out, which I assume will allow anyone to query
> this server for the domains for which it has master or slave records, but
> does not allow the general public to do recursive queries or queries on
> domains not hosted here.
>
> Let me know if I've got that right, or how to correct it if I don't.
>
> If this part is correct I'll continue the questioning.
>
> Thanks!
>
>
>
>
> ___
> 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

Re: Diagnostic help

[Bill Christensen]

So if my server is authoritative for MyDomain.com, should Joe Sixpak be 
able to resolve it via whatever DNS he's using, as mine is currently set up?


Do I need to change it to

|allow-query { any; };|

in order to allow that to happen?  Will my restriction on recursion keep 
the riffraff to a minimum?


Thanks.

On 9/29/14, 7:58 PM, Ben Croswell wrote:


The default for allow query is local host local nets.  Basically the 
server itself and directly connected networks


On Sep 29, 2014 8:03 PM, "Bill Christensen" 
mailto:billc_li...@greenbuilder.com>> 
wrote:


Hi folks,

Something got sideways on one of my DNS servers, and I would
appreciate some help in figuring out what's going on.

I'm running BIND 9.10.1.  This server is authoritative master for
a number of domains.

First off, I may have the allow-query set incorrectly. Currently I
have:

acl query-permit {
(range of IP address on the local LAN which are allowed to use
this server as their query server)
};

acl recursive-permit {
(range of IP address on the local LAN which are allowed to use
this server for recursive queries)
};

acl transfer-permit {
(IP addresses of a couple other name servers allowed to do
transfers with this one)
};

and at the beginning of the options  section:

allow-recursion { recursive-permit; };
 allow-transfer { transfer-permit; };
// allow-query { query-permit; };

Allow-query is commented out, which I assume will allow anyone to
query this server for the domains for which it has master or slave
records, but does not allow the general public to do recursive
queries or queries on domains not hosted here.

Let me know if I've got that right, or how to correct it if I don't.

If this part is correct I'll continue the questioning.

Thanks!




___
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

Re: Diagnostic help

[Matus UHLAR - fantomas]

On 29.09.14 20:58, Ben Croswell wrote:

The default for allow query is local host local nets.  Basically the server
itself and directly connected networks


no, that is the default for allow_recursion (and allow_query_cache).
the default for allow_query is all.


On Sep 29, 2014 8:03 PM, "Bill Christensen" 
wrote:



Allow-query is commented out, which I assume will allow anyone to query
this server for the domains for which it has master or slave records, but
does not allow the general public to do recursive queries or queries on
domains not hosted here.

Let me know if I've got that right, or how to correct it if I don't.


correct.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
___
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: Diagnostic help part 2

[Bill Christensen]

Ok, since I theoretically have the allow-query correct I need to move on 
to what else may be wrong.


When I test with http://www.intodns.com/ or other online tools, I'm 
getting " ERROR: One or more of your nameservers did not respond"  (the 
IP is the server in question)


BIND 9.10.1 *appears* to be running  - named has a PID.

Might it be a problem with system permissions or something like that?

On 9/30/14, 2:41 AM, Matus UHLAR - fantomas wrote:

On 29.09.14 20:58, Ben Croswell wrote:
The default for allow query is local host local nets.  Basically the 
server

itself and directly connected networks


no, that is the default for allow_recursion (and allow_query_cache).
the default for allow_query is all.

On Sep 29, 2014 8:03 PM, "Bill Christensen" 


wrote:



Allow-query is commented out, which I assume will allow anyone to query
this server for the domains for which it has master or slave 
records, but

does not allow the general public to do recursive queries or queries on
domains not hosted here.

Let me know if I've got that right, or how to correct it if I don't.


correct.



___
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: Diagnostic help part 2

[Doug Barton]

On 9/30/14 12:18 PM, Bill Christensen wrote:

Ok, since I theoretically have the allow-query correct I need to move on
to what else may be wrong.

When I test with http://www.intodns.com/ or other online tools, I'm
getting " ERROR: One or more of your nameservers did not respond"  (the
IP is the server in question)

BIND 9.10.1 *appears* to be running  - named has a PID.

Might it be a problem with system permissions or something like that?


If these are domains that are visible on the public Internet, tell us 
the domain names. It's really impossible to guess what might be wrong 
with your setup.


https://dougbarton.us/DNS/bind-users-FAQ.html#RealNames
___
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: Diagnostic help part 2

[Bill Christensen]

Fair enough.

Africabound.org
SustainableSources.com

The server that's giving problems is ns1.sustainablesources.com 
205.238.182.102


(yes, I'm aware of intermittent problems with ns3 as well.  That one's 
not under my control, and I'm moving clients off it.)


Thanks.

On 9/30/14, 2:40 PM, Doug Barton wrote:

On 9/30/14 12:18 PM, Bill Christensen wrote:

Ok, since I theoretically have the allow-query correct I need to move on
to what else may be wrong.

When I test with http://www.intodns.com/ or other online tools, I'm
getting " ERROR: One or more of your nameservers did not respond"  (the
IP is the server in question)

BIND 9.10.1 *appears* to be running  - named has a PID.

Might it be a problem with system permissions or something like that?


If these are domains that are visible on the public Internet, tell us 
the domain names. It's really impossible to guess what might be wrong 
with your setup.


https://dougbarton.us/DNS/bind-users-FAQ.html#RealNames



___
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: Diagnostic help part 2

[Charles Swiger]

Hi--

On Sep 30, 2014, at 1:59 PM, Bill Christensen  
wrote:
> Fair enough.  
> 
> Africabound.org
> SustainableSources.com
> 
> The server that's giving problems is ns1.sustainablesources.com 
> 205.238.182.102

Your 102 box doesn't seem responding to 53/udp or 53/tcp from the outside:

  http://www.dnsinspect.com/sustainablesources.com/1412110958

There's a bunch of other issues.  In particular, BIND 9.6-ESV is the oldest 
version
which anyone should be running on the public internet, and even that is 
sufficiently
obsolete that I think support for that ended this year.

Regards,
-- 
-Chuck

___
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: Diagnostic help part 2

[Bill Christensen]

On 9/30/14, 4:15 PM, Charles Swiger wrote:

Hi--

On Sep 30, 2014, at 1:59 PM, Bill Christensen 
mailto:billc_li...@greenbuilder.com>> 
wrote:

Fair enough.

Africabound.org 


SustainableSources.com

The server that's giving problems is ns1.sustainablesources.com 
205.238.182.102


Your 102 box doesn't seem responding to 53/udp or 53/tcp from the outside:

http://www.dnsinspect.com/sustainablesources.com/1412110958

There's a bunch of other issues.  In particular, BIND 9.6-ESV is the 
oldest version
which anyone should be running on the public internet, and even that 
is sufficiently

obsolete that I think support for that ended this year.

Regards,
--
-Chuck

I'm aware that the BIND 9.6 on the other machine is rather ancient, and 
have plans to move off it in the reasonably near future.  And the other 
issues.  Trying to clean them all up.


But I still have the initial problem of getting 
ns1.sustainablesources.com 205.238.182.102 to answer.  This is a clean 
install of the latest BIND available, after a system upgrade, so there's 
probably something wrong with my config.  Problem is, I don't know 
what.  I've been over it dozens of times and am stuck, otherwise I 
wouldn't have posted here.


Is it kosher to post the config file here?
___
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: Diagnostic help part 2

[Rich Goodson]

If named is running and doesn’t respond on the external interface, it’s 
possible that your listen-on {}; directive is set to only localhost.

TCP connections to 205.238.182.102 come back “Connection refused”, so it’s 
possible that BIND just isn’t listening on the interface or perhaps you’re 
filtering the inbound queries.   Do you see the queries come in to the box, 
either via packet dump or query logs?


-Rich


On Sep 30, 2014, at 5:30 PM, Bill Christensen  
wrote:

> On 9/30/14, 4:15 PM, Charles Swiger wrote:
>> Hi--
>> 
>> On Sep 30, 2014, at 1:59 PM, Bill Christensen  
>> wrote:
>>> Fair enough.  
>>> 
>>> Africabound.org
>>> SustainableSources.com
>>> 
>>> The server that's giving problems is ns1.sustainablesources.com 
>>> 205.238.182.102
>> 
>> Your 102 box doesn't seem responding to 53/udp or 53/tcp from the outside:
>> 
>>   http://www.dnsinspect.com/sustainablesources.com/1412110958
>> 
>> There's a bunch of other issues.  In particular, BIND 9.6-ESV is the oldest 
>> version
>> which anyone should be running on the public internet, and even that is 
>> sufficiently
>> obsolete that I think support for that ended this year.
>> 
>> Regards,
>> -- 
>> -Chuck
>> 
> I'm aware that the BIND 9.6 on the other machine is rather ancient, and have 
> plans to move off it in the reasonably near future.  And the other issues.  
> Trying to clean them all up. 
> 
> But I still have the initial problem of getting ns1.sustainablesources.com 
> 205.238.182.102 to answer.  This is a clean install of the latest BIND 
> available, after a system upgrade, so there's probably something wrong with 
> my config.  Problem is, I don't know what.  I've been over it dozens of times 
> and am stuck, otherwise I wouldn't have posted here. 
> 
> Is it kosher to post the config file here?  
> ___
> 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



smime.p7s
Description: S/MIME cryptographic 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

RE: Diagnostic help part 2

[John Anderson]

>If named is running and doesn't respond on the external interface, it's 
>possible that your listen-on {}; directive is set to only localhost.

>TCP connections to 205.238.182.102 come back "Connection refused", so 
>it's possible that BIND just isn't listening on the interface or perhaps 
>you're filtering the inbound queries.   Do you see the queries come in to 
>the box, either via packet dump or query logs?


Is your BIND server behind a firewall?  Is it only listening on localhost, or 
on an internal interface?  If '~]$ netstat -nlp | grep named' tells you that 
named is only listening on 127.0.0.1:53, then you need to adjust listen-on in 
named.conf.  If you are running iptables, you need to allow at least UDP/53 in, 
if this is a master transferring to slaves, it might be a good idea to allow 
TCP/53 in as well.   If you are behind a firewall, you need to open up UDP/53 
or port forward UDP/53 to your bind server.

Here's what I see when looking at the IP you provided:

~]$ sudo nmap -sT -sU -p 53 205.238.182.102

Starting Nmap 5.51 ( http://nmap.org ) at 2014-09-30 16:02 MST
Nmap scan report for www3.greenbuilder.com (205.238.182.102)
Host is up (1.1s latency).
PORT   STATE  SERVICE
53/tcp closed domain
53/udp closed domain

Here is what I should see, using Google's DNS server as an example:

~]$ sudo nmap -sT -sU -p 53 8.8.8.8

Starting Nmap 5.51 ( http://nmap.org ) at 2014-09-30 16:03 MST
Nmap scan report for google-public-dns-a.google.com (8.8.8.8)
Host is up (0.062s latency).
PORT   STATE SERVICE
53/tcp open  domain
53/udp open|filtered domain

John A.
___
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: Diagnostic help part 2

[Bill Christensen]

On 9/30/14, 5:52 PM, Rich Goodson wrote:
If named is running and doesn't respond on the external interface, 
it's possible that your listen-on {}; directive is set to only localhost.


You may have hit on hit there.  It was set to
listen-on { 127.0.0.1; };

I just changed that to:
listen-on { 205.238.182.102; };
and it appears to have made all the difference.

I'm no longer seeing the errors from (at least, some of) the online DNS 
tests that 102 doesn't respond.  I'm guessing the others have cached 
info from lookups earlier today.


Please let me know if you see otherwise.

Now to get on with some of the other cleanup tasks.

Thanks for the help.


TCP connections to 205.238.182.102 come back "Connection refused", so 
it's possible that BIND just isn't listening on the interface or 
perhaps you're filtering the inbound queries.   Do you see the queries 
come in to the box, either via packet dump or query logs?



-Rich


On Sep 30, 2014, at 5:30 PM, Bill Christensen 
mailto:billc_li...@greenbuilder.com>> 
wrote:



On 9/30/14, 4:15 PM, Charles Swiger wrote:

Hi--

On Sep 30, 2014, at 1:59 PM, Bill Christensen 
mailto:billc_li...@greenbuilder.com>> 
wrote:

Fair enough.

Africabound.org 


SustainableSources.com 

The server that's giving problems is ns1.sustainablesources.com 
 205.238.182.102


Your 102 box doesn't seem responding to 53/udp or 53/tcp from the 
outside:


http://www.dnsinspect.com/sustainablesources.com/1412110958

There's a bunch of other issues.  In particular, BIND 9.6-ESV is the 
oldest version
which anyone should be running on the public internet, and even that 
is sufficiently

obsolete that I think support for that ended this year.

Regards,
--
-Chuck

I'm aware that the BIND 9.6 on the other machine is rather ancient, 
and have plans to move off it in the reasonably near future.  And the 
other issues.  Trying to clean them all up.


But I still have the initial problem of getting 
ns1.sustainablesources.com  
205.238.182.102 to answer.  This is a clean install of the latest 
BIND available, after a system upgrade, so there's probably something 
wrong with my config. Problem is, I don't know what.  I've been over 
it dozens of times and am stuck, otherwise I wouldn't have posted here.


Is it kosher to post the config file here?
___
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


___
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: Diagnostic help part 2

[Eli Heady]

On Sep 30, 2014 7:11 PM, "John Anderson" @
ccbill.com > wrote:
>
> >If named is running and doesn't respond on the external interface, it's
> >possible that your listen-on {}; directive is set to only localhost.
>
> >TCP connections to 205.238.182.102 come back "Connection refused", so
> >it's possible that BIND just isn't listening on the interface or perhaps
> >you're filtering the inbound queries.   Do you see the queries come in to
> >the box, either via packet dump or query logs?
>
>
> Is your BIND server behind a firewall?  Is it only listening on
localhost, or on an internal interface?  If '~]$ netstat -nlp | grep named'
tells you that named is only listening on127.0.0.1 :53
, then you need to adjust listen-on in named.conf.  If
you are running iptables, you need to allow at least UDP/53 in, if this is
a master transferring to slaves, it might be a good idea to allow TCP/53 in
as well.   If you are behind a firewall, you need to open up UDP/53 or port
forward UDP/53 to your bind server.
>

I know Bill's issue is solved, but I want to point out that anyone running
DNS would be wise to not block TCP/53. TCP service for queries is specified
in the protocol design, and not just for transfers. Failing UDP queries
should result in retries over TCP

With response sizes growing (dnssec, ipv6), answers are more likely to be
too large for UDP.

If you enable response rate limiting (try it, you'll like it), you must
also respond to TCP queries. The RRL implementation is designed to cause
legitimate clients to retry queries over TCP.

There are a variety of reasons UDP  responses won't make it to clients,
many of which are outside your control. Not offering TCP service means
clients that can't reliably get UDP responses likely won't get any answer
from your servers at all.

Eli
___
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: Diagnostic help part 2

[Barry Margolin]

In article ,
 Eli Heady  wrote:

> With response sizes growing (dnssec, ipv6), answers are more likely to be
> too large for UDP.

That's unlikely. That's why EDNS was created, so that these large 
answers wouldn't require TCP.

-- 
Barry Margolin
Arlington, MA
___
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: Diagnostic help part 2

[Doug Barton]

On 10/1/14 8:17 AM, Barry Margolin wrote:

In article ,
  Eli Heady  wrote:


With response sizes growing (dnssec, ipv6), answers are more likely to be
too large for UDP.


That's unlikely. That's why EDNS was created, so that these large
answers wouldn't require TCP.


... and more than a decade later EDNS still fails very often due to 
misconfigured and/or ancient firewalls that don't understand it. 53/TCP 
is part of the spec, and should not be blocked.


Doug


___
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: Diagnostic help part 2

[Mike Hoskins (michoski)]

-Original Message-
From: Doug Barton 
Date: Wednesday, October 1, 2014 at 2:07 PM
To: "bind-users@lists.isc.org" 
Subject: Re: Diagnostic help part 2

>On 10/1/14 8:17 AM, Barry Margolin wrote:
>> In article ,
>>   Eli Heady  wrote:
>>
>>> With response sizes growing (dnssec, ipv6), answers are more likely to
>>>be
>>> too large for UDP.
>>
>> That's unlikely. That's why EDNS was created, so that these large
>> answers wouldn't require TCP.
>
>... and more than a decade later EDNS still fails very often due to
>misconfigured and/or ancient firewalls that don't understand it. 53/TCP
>is part of the spec, and should not be blocked.

This isn't even specific to DNS...for example, there was a time when just
"turning on what sounds good" for cisco, netscreen and even checkpoint
would break other things like ESMTP.  As an admin you needed to test your
changes and understand the protocol...many don't.

It's just far worse for DNS, since there was a time when many
well-intentioned checklists suggested locking down 53/tcp.  So in this
case DNS admins were reading docs, just the wrong ones.  RTRFM.  :-)

___
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: Diagnostic help part 2

[Tony Finch]

Mike Hoskins (michoski)  wrote:
>
> This isn't even specific to DNS...for example, there was a time when just
> "turning on what sounds good" for cisco, netscreen and even checkpoint
> would break other things like ESMTP.

You mean Cisco have fixed the grossly damaging bugs in the PIX/ASA
application layer filters?

My favourite one is its insufficient cross-packet state, and habit of
ing out commands it does not understand, which leads to it ing out
RCPT commands that happen to be split between packets, leading to things
like people being unsubscribed from mailing lists.

(Sorry for straying off topic. I have less experience of Cisco PIX/ASA
breaking DNS than of them breaking SMTP.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.
___
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: Diagnostic help part 2

[John Anderson]

>If you would be so kind as to run the nmap test again from your location and 
>let >me know if you're seeing the correct - or at least *more* correct 
>answers, I'd >appreciate it.

Bill,

It looks good now.

Starting Nmap 5.51 ( http://nmap.org ) at 2014-10-01 12:47 MST
Nmap scan report for www3.greenbuilder.com (205.238.182.102)
Host is up (0.087s latency).
PORT   STATE SERVICE
53/tcp open  domain
53/udp open  domain

>I know Bill's issue is solved, but I want to point out that anyone running DNS 
>>would be wise to not block TCP/53. TCP service for queries is specified in 
>the >protocol design, and not just for transfers. Failing UDP queries should 
>result in >retries over TCP
>With response sizes growing (dnssec, ipv6), answers are more likely to be too 
>>large for UDP.

Eli,

Good advice leaving TCP/53 open as well.  I haven't done much in the way of 
IPv6, but one thing is certain.  It's coming, and DNS responses aren't going to 
get any smaller.   It's best to be future ready.

Thanks!

John A.


___
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: Diagnostic help part 2

[Mark Andrews]

In message <5D9044356DCF9341A7D1CDAE12FC601C2976D2A5@exch10-mb2.ccbill-hq.local
>, John Anderson writes:
> >If you would be so kind as to run the nmap test again from your location and
>  let >me know if you're seeing the correct - or at least *more* correct answe
> rs, I'd >appreciate it.
> 
> Bill,
> 
> It looks good now.
> 
> Starting Nmap 5.51 ( http://nmap.org ) at 2014-10-01 12:47 MST
> Nmap scan report for www3.greenbuilder.com (205.238.182.102)
> Host is up (0.087s latency).
> PORT   STATE SERVICE
> 53/tcp open  domain
> 53/udp open  domain
> 
> >I know Bill's issue is solved, but I want to point out that anyone running D
> NS >would be wise to not block TCP/53. TCP service for queries is specified i
> n the >protocol design, and not just for transfers. Failing UDP queries shoul
> d result in >retries over TCP
> >With response sizes growing (dnssec, ipv6), answers are more likely to be to
> o >large for UDP.
> 
> Eli,
> 
> Good advice leaving TCP/53 open as well.  I haven't done much in the way of I
> Pv6, but one thing is certain.  It's coming, and DNS responses aren't going t
> o get any smaller.   It's best to be future ready.

TCP has always been required for DNS except in very special
circumstances.  Go read RFC 1123.  Go look at the definition of
SHOULD.  Unless you really knew what you were doing TCP as always
been expected to be ON.

There was a myth the TCP was only required for zone transfers.  It
was NEVER fact.  There were so many case of people getting it wrong
that we now have a RFC that states that TCP is a MUST for DNS.

It has NEVER been safe for a recursive server to not support TCP
if you were connected to the Internet.  The only place were that
would be safe is if you controlled all the authoritative servers
and all possible queries would not result in TC=1 being set.

There is also a myth that TC=1 does not need to be set for anything
that you put in the additional section.  This is also has never
been true.  Failure to insert glue records requires TC=1 to be set.
With EDNS, TSIG and SIG(0) there are even more cases where TC=1
should be set if records can't fit in the additional section.

We are still having to hack authoritative servers so as to not break
DNS lookups for idiots that turn off TCP on recursive servers.  TC=1
should be set more often that it currently is.  Every referral from
the root server to the COM and NET server for plain DNS should have
TC=1 set these days as the all the glue no longer fits.

Mark

> Thanks!
> 
> John A.
> 
> 
> ___
> 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
-- 
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: Diagnostic help part 2

[Bill Christensen]

Thanks!  That cleared up a number of problems.

Now to tackle some of the others...

On 10/1/14, 2:51 PM, John Anderson wrote:

If you would be so kind as to run the nmap test again from your location and let 
>me know if you're seeing the correct - or at least *more* correct answers, I'd 
>appreciate it.

Bill,

It looks good now.

Starting Nmap 5.51 ( http://nmap.org ) at 2014-10-01 12:47 MST
Nmap scan report for www3.greenbuilder.com (205.238.182.102)
Host is up (0.087s latency).
PORT   STATE SERVICE
53/tcp open  domain
53/udp open  domain




___
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: Diagnostic help part 2

[Anders Löwinger]

On 2014-10-02 01:03, Mark Andrews wrote:
> TCP has always been required for DNS except in very special
> circumstances.  Go read RFC 1123.  Go look at the definition of
> SHOULD.  Unless you really knew what you were doing TCP as always
> been expected to be ON.

Some people refuse to enable stuff unless there is a Standard,
thats why I really like RFC5966 :)


   his document therefore updates the core DNS protocol specifications
   such that support for TCP is henceforth a REQUIRED part of a full DNS
   protocol implementation.


/Anders

___
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: Diagnostic help part 2

[Dave Sparro]

On 10/1/2014 3:45 PM, Tony Finch wrote:

(Sorry for straying off topic. I have less experience of Cisco PIX/ASA
breaking DNS than of them breaking SMTP.)

I can't resist either..
I specifically remember a PIX that bit me by "helpfully" changing the 
payload of an axfr so that the A records that traveled through the PIX's 
NAT got flipped to the inside RFC-1918 addresses for the servers that 
were behind the NAT as well.


It took a couple rounds of "your sending me the wrong stuff... No I'm 
Not!" until we figured it out.

___
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: Diagnostic help part 2

[Mike Hoskins (michoski)]

-Original Message-
From: Dave Sparro 
Date: Friday, October 3, 2014 at 1:04 PM
To: "bind-users@lists.isc.org" 
Subject: Re: Diagnostic help part 2

>On 10/1/2014 3:45 PM, Tony Finch wrote:
>> (Sorry for straying off topic. I have less experience of Cisco PIX/ASA
>> breaking DNS than of them breaking SMTP.)
>I can't resist either..
>I specifically remember a PIX that bit me by "helpfully" changing the
>payload of an axfr so that the A records that traveled through the PIX's
>NAT got flipped to the inside RFC-1918 addresses for the servers that
>were behind the NAT as well.
>
>It took a couple rounds of "your sending me the wrong stuff... No I'm
>Not!" until we figured it out.

Yeah, I've had similar experiences on various platforms over the years...
I know it's hard for smaller shops, but even when I was in startup land I
built labs to validate design and behavior (the difference was the "labs"
were often under my desk or in a closet).

Finding unexpected behavior like this in production is always stressful.
Ultimately, we have a responsibility as engineers/architects to conduct
due diligence and not make assumptions.  Testing and validation are key
parts of our job.  Anything made by people can have bugs or simply
unexpected behavior.  :-)

___
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

Failing DNS Server Diagnostic Help Requested

[Tim Daneliuk via bind-users]

Environment:  Master/Slave with Split Horizon both on FreeBSD-STABLE
  Bind 9.16.24_1
  Master out in a cloud server
  Slave on a physical server with a static IP on Comcast Business

Problem:  After years of stable behavior, Slave intermittently not resolving
  addresses a few months ago, and then completely stopped working
  yesterday. We also noticed that the Slave will not update its files
  upon notify from the Master.

Action Taken: Replaced Slave with a clone of the Master instance.  That new
  Master does properly resolve names inside our zone, whether
  the requestor is on our LAN our one of our trusted servers out
  on the internet that are allowed to see internal names.

  HOWEVER, that new master instance will not resolve names in
  zones other than ours.  We're working around this by
  forwarding these failed lookups to our original master -
  that is working fine.

  So, we have two masters with the same configuration and
  tables, but one resolves outside names and one does not.
  We've tried disabling DNSSEC validation and opening up our
  firewalls and got nowhere.

  When the lookups outside our zone fail, we see this:

13-Jan-2022 14:28:09.702 resolver: notice: DNS format error from 
192.203.230.10#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.702 lame-servers: info: FORMERR resolving './NS/IN': 
192.203.230.10#53
13-Jan-2022 14:28:09.721 resolver: notice: DNS format error from 
192.36.148.17#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.721 lame-servers: info: FORMERR resolving './NS/IN': 
192.36.148.17#53
13-Jan-2022 14:28:09.741 resolver: notice: DNS format error from 
193.0.14.129#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.741 lame-servers: info: FORMERR resolving './NS/IN': 
193.0.14.129#53
13-Jan-2022 14:28:09.763 resolver: notice: DNS format error from 199.7.91.13#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.763 lame-servers: info: FORMERR resolving './NS/IN': 
199.7.91.13#53
13-Jan-2022 14:28:09.781 resolver: notice: DNS format error from 
202.12.27.33#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.781 lame-servers: info: FORMERR resolving './NS/IN': 
202.12.27.33#53
13-Jan-2022 14:28:09.801 resolver: notice: DNS format error from 199.7.83.42#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.801 lame-servers: info: FORMERR resolving './NS/IN': 
199.7.83.42#53
13-Jan-2022 14:28:09.820 resolver: notice: DNS format error from 
192.58.128.30#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.820 lame-servers: info: FORMERR resolving './NS/IN': 
192.58.128.30#53
13-Jan-2022 14:28:09.837 resolver: notice: DNS format error from 198.41.0.4#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.837 lame-servers: info: FORMERR resolving './NS/IN': 
198.41.0.4#53
13-Jan-2022 14:28:09.855 resolver: notice: DNS format error from 
198.97.190.53#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.855 lame-servers: info: FORMERR resolving './NS/IN': 
198.97.190.53#53
13-Jan-2022 14:28:09.875 resolver: notice: DNS format error from 192.5.5.241#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.875 lame-servers: info: FORMERR resolving './NS/IN': 
192.5.5.241#53
13-Jan-2022 14:28:09.893 resolver: notice: DNS format error from 
192.112.36.4#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.893 lame-servers: info: FORMERR resolving './NS/IN': 
192.112.36.4#53
13-Jan-2022 14:28:09.921 resolver: notice: DNS format error from 
199.9.14.201#53 resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.921 lame-servers: info: FORMERR resolving './NS/IN': 
199.9.14.201#53
13-Jan-2022 14:28:09.937 resolver: notice: DNS format error from 192.33.4.12#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.937 lame-servers: info: FORMERR resolving './NS/IN': 
192.33.4.12#53
13-Jan-2022 14:28:09.938 resolver: info: resolver priming query complete


So ... could this be Comcast munging about in the DNS traffic?   Other 
suggestions
of where to look appreciated as well ...


(We have a fair bit of other logging data to be examined, I just didn't want to
spam the whole list with all that ...)


-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.i

Re: Failing DNS Server Diagnostic Help Requested

[Matus UHLAR - fantomas]

On 13.01.22 14:29, Tim Daneliuk via bind-users wrote:

Environment:  Master/Slave with Split Horizon both on FreeBSD-STABLE
 Bind 9.16.24_1
 Master out in a cloud server
 Slave on a physical server with a static IP on Comcast Business

Problem:  After years of stable behavior, Slave intermittently not resolving
 addresses a few months ago, and then completely stopped working
 yesterday. We also noticed that the Slave will not update its files
 upon notify from the Master.

Action Taken: Replaced Slave with a clone of the Master instance.  That new
 Master does properly resolve names inside our zone, whether
 the requestor is on our LAN our one of our trusted servers out
 on the internet that are allowed to see internal names.

 HOWEVER, that new master instance will not resolve names in
 zones other than ours.  We're working around this by
 forwarding these failed lookups to our original master -
 that is working fine.

 So, we have two masters with the same configuration and
 tables, but one resolves outside names and one does not.
 We've tried disabling DNSSEC validation and opening up our
 firewalls and got nowhere.

 When the lookups outside our zone fail, we see this:

13-Jan-2022 14:28:09.702 resolver: notice: DNS format error from 192.203.230.10#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.702 lame-servers: info: FORMERR resolving './NS/IN': 
192.203.230.10#53
13-Jan-2022 14:28:09.721 resolver: notice: DNS format error from 192.36.148.17#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.721 lame-servers: info: FORMERR resolving './NS/IN': 
192.36.148.17#53
13-Jan-2022 14:28:09.741 resolver: notice: DNS format error from 193.0.14.129#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.741 lame-servers: info: FORMERR resolving './NS/IN': 
193.0.14.129#53
13-Jan-2022 14:28:09.763 resolver: notice: DNS format error from 199.7.91.13#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.763 lame-servers: info: FORMERR resolving './NS/IN': 
199.7.91.13#53
13-Jan-2022 14:28:09.781 resolver: notice: DNS format error from 202.12.27.33#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.781 lame-servers: info: FORMERR resolving './NS/IN': 
202.12.27.33#53
13-Jan-2022 14:28:09.801 resolver: notice: DNS format error from 199.7.83.42#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.801 lame-servers: info: FORMERR resolving './NS/IN': 
199.7.83.42#53
13-Jan-2022 14:28:09.820 resolver: notice: DNS format error from 192.58.128.30#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.820 lame-servers: info: FORMERR resolving './NS/IN': 
192.58.128.30#53
13-Jan-2022 14:28:09.837 resolver: notice: DNS format error from 198.41.0.4#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.837 lame-servers: info: FORMERR resolving './NS/IN': 
198.41.0.4#53
13-Jan-2022 14:28:09.855 resolver: notice: DNS format error from 198.97.190.53#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.855 lame-servers: info: FORMERR resolving './NS/IN': 
198.97.190.53#53
13-Jan-2022 14:28:09.875 resolver: notice: DNS format error from 192.5.5.241#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.875 lame-servers: info: FORMERR resolving './NS/IN': 
192.5.5.241#53
13-Jan-2022 14:28:09.893 resolver: notice: DNS format error from 192.112.36.4#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.893 lame-servers: info: FORMERR resolving './NS/IN': 
192.112.36.4#53
13-Jan-2022 14:28:09.921 resolver: notice: DNS format error from 199.9.14.201#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.921 lame-servers: info: FORMERR resolving './NS/IN': 
199.9.14.201#53
13-Jan-2022 14:28:09.937 resolver: notice: DNS format error from 192.33.4.12#53 
resolving ./NS for : non-improving referral
13-Jan-2022 14:28:09.937 lame-servers: info: FORMERR resolving './NS/IN': 
192.33.4.12#53
13-Jan-2022 14:28:09.938 resolver: info: resolver priming query complete


So ... could this be Comcast munging about in the DNS traffic?


looks like exactly it. 


  Other suggestions
of where to look appreciated as well ...


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.or