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. ___ 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
-Original Message- From: Dave Sparro dspa...@gmail.com Date: Friday, October 3, 2014 at 1:04 PM To: bind-users@lists.isc.org 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
Re: Diagnostic help part 2
In article mailman.1035.1412133286.26362.bind-us...@lists.isc.org, Eli Heady eli.he...@gmail.com 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
On 10/1/14 8:17 AM, Barry Margolin wrote: In article mailman.1035.1412133286.26362.bind-us...@lists.isc.org, Eli Heady eli.he...@gmail.com 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
-Original Message- From: Doug Barton do...@dougbarton.us Date: Wednesday, October 1, 2014 at 2:07 PM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: Diagnostic help part 2 On 10/1/14 8:17 AM, Barry Margolin wrote: In article mailman.1035.1412133286.26362.bind-us...@lists.isc.org, Eli Heady eli.he...@gmail.com 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
Mike Hoskins (michoski) micho...@cisco.com 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.finch d...@dotat.at http://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
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
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
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
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 :) snip 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. /snip /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
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 billc_li...@greenbuilder.com 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
Fair enough. http://localhost:10800/bind8/edit_master.cgi?zone=Africabound.orgAfricabound.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
Hi-- On Sep 30, 2014, at 1:59 PM, Bill Christensen 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 ___ 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
On 9/30/14, 4:15 PM, Charles Swiger wrote: Hi-- On Sep 30, 2014, at 1:59 PM, Bill Christensen billc_li...@greenbuilder.com mailto:billc_li...@greenbuilder.com wrote: Fair enough. http://localhost:10800/bind8/edit_master.cgi?zone=Africabound.orgAfricabound.org http://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
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
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
billc_li...@greenbuilder.com 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
billc_li...@greenbuilder.com mailto:billc_li...@greenbuilder.com
wrote:
Fair enough.
http://localhost:10800/bind8/edit_master.cgi?zone=Africabound.orgAfricabound.org
http://africabound.org/
SustainableSources.com http://SustainableSources.com
The server that's giving problems is ns1.sustainablesources.com
http://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 http://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 mailto: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
