Re: Free secondary servers supporting DNSSEC?
On 02/17/2013 12:11 PM, Vernon Schryver wrote: From: Robert Moskowitz r...@htt-consult.com The Redhat docs on bind had a warning about not implementing features, like DNSSEC if your secondaries doesn't support it. That is all I am going on. I think I also saw it in some isc.org doc. In your position, I'd publish the RRSIG and NSEC* records (i.e. sign the zone) and see what breaks. Maybe I'm ignorant and naive about DNSSEC (I'd like to hear about it), but I'd expect nothing bad to happen with the secondaries. And if they're running such incredibly ancient code that something breaks, then they probably have serious security issues unrelated to DNSSEC that should disqualify them as secondaries. You'll have to do something like that while you fight with Network Solutions to deal with your DS records or switch to another registrar. Hmm. My renewal is right about now. Perhaps I SHOULD switch at this time... I got my domain from them back in '95 and ran it on some NT code for a number of years. My recollections of past mailing list comments as well as https://www.google.com/search?q=network+solutions+dnssec https://www.networksolutions.com/search.jsp?searchTerm=dnssec https://www.icann.org/en/news/in-focus/dnssec/deployment suggest that effort will be interesting. Have you started it? At the end of a long saga to get DS RRs for the handful of my domains, Tucows/Opensrs said Please try not ask us do that again soon. ___ 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: IPv6 prefixes in ACLs
On 02/17/2013 12:43 PM, Evan Hunt wrote: Should I put a single entry for my /48 allocation or 16 /64 entries for the nets I am currently using? Both ways work. Does it make any difference for performance? Possibly, but I doubt you could measure it. (Unless you're using a really ancent version of BIND, in which case the shorter list is better.) This whole adventure is to finally get current! Well at least as current as Redhat (actually Centos) provides :) ::1/128 ; 2001:0db8:100::4/128; Is what you do for specific addresses? You don't need the /128. Nice to know that the format is consistant across address times. 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: empty-zones not set warning, but have net 192.168.128/24
On 02/16/2013 07:25 PM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: I have been getting this warning, and wonder why? I have read: https://kb.isc.org/article/AA-00804/0/Why-does-named-log-an-error-disabling-RFC-1918-empty-zones-when-starting-up.html named logs the message if there are any RFC 1918 zones that ought to be configured but are not. OK. I read that article to say if you specified one RFC 1918 address (I was a co-author), then you would not get this warning. It is assumed that then you know about them and the one(s) you include is all you will have. It would be nice if bind was smart enough to supply those you don't need. I have a 128.168.192.in-addr.arpa.zone zone in my internal view. So what might I be missing? Do I need to create my own delegation tree? Set empty-zones-enable yes; Got it. OK. ___ 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
IPv6 prefixes in ACLs
Should I put a single entry for my /48 allocation or 16 /64 entries for the nets I am currently using? Does it make any difference for performance? Any other concerns? The 192.168 nets I use I have a /24 specified though typically I am only using the lower /26. In theory, no one out there can 'take over' my unused space without action by my ISP (which some time in the future if they start running out of IPv6 prefixes for their customers they might ask for some back). Oh, and examples I am finding for specific addresses show v4 addresses plain like: 127.0.0.1; 10.5.4.5; But with a /128 'prefix' for v6 addresses: ::1/128 ; 2001:0db8:100::4/128; Is what you do for specific addresses? ___ 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: Building a fresh named.root
On 02/15/2013 12:37 PM, Chris Buxton wrote: On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grepA.ROOT-SERVERS.NET http://A.ROOT-SERVERS.NET/ returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. I have a /48 allocated to my home lab :) (I also have a /26 IPv4 allocation here) - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. ___ 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
rndc.key
I am now running without chroot and relying on selinux for protection. I created a /etc/named.d/ directory for all my many includes in named.conf which I know I have to keep in /etc/ My rndc.key is in /etc/named.d/ and is an include in my named.conf. When I first started bind, it reported that it was creating rndc.key and now I find /etc/rndc.key. rndc is working, that is it returns results from commands like 'rndc status'. What is going on here? Which rndc.key is being used? thank you. ___ 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
Randoming ports and firewall rules
So it is past time for me to only use port 53 and support port randomization. But I do run iptables (and ip6tables) and the server sits behind a Juniper SSG firewall. Where are there instructions for setting up iptables for port randomization and for general firewall rules (I doubt I will find specific for my Juniper). thank you. More questions to come as I peel this onion! I am rather behind the times! ___ 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
builtin hints working - Re: Building a fresh named.root
I commented out include for the root.hints and things are working still so obviously it is built in even though the string search is not working on my binary. On 02/15/2013 12:57 PM, Robert Moskowitz wrote: On 02/15/2013 12:37 PM, Chris Buxton wrote: On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grepA.ROOT-SERVERS.NET http://A.ROOT-SERVERS.NET/ returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. I have a /48 allocated to my home lab :) (I also have a /26 IPv4 allocation here) - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. ___ 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
empty-zones not set warning, but have net 192.168.128/24
I have been getting this warning, and wonder why? I have read: https://kb.isc.org/.../Why-does-named-log-an-error-disabling-RFC-1918-empty-zones-when-starting-up.html I have a 128.168.192.in-addr.arpa.zone zone in my internal view. So what might I be missing? Do I need to create my own delegation tree? ___ 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: Building a fresh named.root
On 02/15/2013 03:40 PM, Chris Buxton wrote: On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote: I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. Appearently so. Very interesting. using my IP address and I got a nice return back of the root servers. Just like I get from the 'real ones'. And I have commented out the hint stub, so I am good on this matter. One more item checked off. 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: Building a fresh named.root
On 02/15/2013 03:40 PM, Chris Buxton wrote: On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote: I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. I just looked at the dig results using localhost again, and there it was, ::1! I also realize that I have to add my IPv6 prefix to my allowed internal addresses, along with ::1 ___ 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: Building a fresh named.root
On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz r...@htt-consult.com wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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: Building a fresh named.root
Oops ignore that earlier send. Hit wrong button... On 02/14/2013 08:42 AM, Steven Carr wrote: On 14 February 2013 13:35, Robert Moskowitz r...@htt-consult.com wrote: What went wrong here? Which do I use? Not sure what is up with your dig response (can you post the contents) but it works for me and if your dig still isn't working use the one from FTP. sjcarr@elmo:~ $ dig . ns @198.41.0.4 ; DiG 9.8.3-P1 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6958 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS Stuff deleted. ;; ADDITIONAL SECTION: j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 e.root-servers.net. 360 IN A 192.203.230.10 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 g.root-servers.net. 360 IN A 192.112.36.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 l.root-servers.net. 360 IN 2001:500:3::42 ;; Query time: 44 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 13:40:13 2013 ;; MSG SIZE rcvd: 508 You too are missing some A and records! Here is mine: ; DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 57006 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS f.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS l.root-servers.net. ;; ADDITIONAL SECTION: f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 c.root-servers.net. 360 IN A 192.33.4.12 m.root-servers.net. 360 IN 2001:dc3::35 ;; Query time: 221 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 08:08:32 2013 ;; MSG SIZE rcvd: 508 ___ 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: Building a fresh named.root
On 02/14/2013 09:19 AM, Christian Tardif wrote: You're right. CentOS 6.3 does not have named.root. They just call it named.ca. That's actually the same file thing. You just need to refer to the right file name for hints. Note below that I did see the named.ca which is from their namecaching setup. And this stub does not have as many records as the one I ftped, so it is already dated. Which begs the next question I was going to ask. How often should I download a fresh named.zone? Do I set up a monthly cron job? It is clear that there is movement on populating it with records. Christian... On 02/14/2013 08:35 AM, Robert Moskowitz wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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: Building a fresh named.root
On 02/14/2013 09:34 AM, Warren Kumari wrote: On Feb 14, 2013, at 9:28 AM, Robert Moskowitz r...@htt-consult.com wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. Nope -- it is in lib/dns/rootns.c in the source code tree…. Oh, of course... When BIND is compiled into a binary this gets baked in…. You can verify this by running strings on the binary. E.g: wkumari$:~$ strings /usr/local/sbin/named | grep A.ROOT-SERVERS.NET . 518400 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 360 IN 2001:503:BA3E::2:30 Mine is located in /usr/sbin/ and no such string. In fact the only occurance of ROOT is a comment on the location of the ROOT KEY. And anyway, baking it in is a problem as we continue to have an availablity of for the roots. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz r...@htt-consult.com wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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: Building a fresh named.root
On 02/14/2013 09:38 AM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. That is a source file name which is compiled into the binary. You don't need any extra files in the installation. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? The default is to use the built-in hints. That makes sense. Smart people that put this together ;) Given the expansion of records, I think I am going to stay with an explicit root file this time around. ___ 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: Building a fresh named.root
On 02/14/2013 09:47 AM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: Which begs the next question I was going to ask. How often should I download a fresh named.zone? Never. If you keep BIND reasonably up-to-date its built-in hints will work fine. More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). Is there a way I can DIG my server for what it thinks . is? Like using that same DIG command? I am still checking out my files and have not started bind, but I should be ready shortly... ___ 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: Building a fresh named.root
On 02/14/2013 10:18 AM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Thanks. Now I just have to find out from the Centos list if my version has them built in. Even if they are 15 years out of date it will still work, because the root name servers do not change very often. And with anycast they will probably not change until IPv9... Check out RFC 1606. ___ 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: Building a fresh named.root
On 02/14/2013 10:26 AM, Jaap Akkerhuis wrote: You too are missing some A and records! Here is mine: Use bufsize=4096 or at least something around 700, else the answer doesn't fitand is truncated. I was thinking it was something like that. Thanks. jaap dig +bufsize=4096 . ns @198.41.0.4 ; DiG 9.8.4-P1 +bufsize=4096 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33099 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 23 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS f.root-servers.net. ;; ADDITIONAL SECTION: d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 b.root-servers.net. 360 IN A 192.228.79.201 c.root-servers.net. 360 IN A 192.33.4.12 i.root-servers.net. 360 IN 2001:7fe::53 i.root-servers.net. 360 IN A 192.36.148.17 m.root-servers.net. 360 IN 2001:dc3::35 m.root-servers.net. 360 IN A 202.12.27.33 e.root-servers.net. 360 IN A 192.203.230.10 l.root-servers.net. 360 IN 2001:500:3::42 l.root-servers.net. 360 IN A 199.7.83.42 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 ;; Query time: 19 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 16:24:06 2013 ;; MSG SIZE rcvd: 699 ___ 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
chroot/etc/named/ directory?
I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in Centos 6.3. I have and will run bind chrooted and on my test setup I noticed a 'new' subdirectory in the chroot tree: /var/named/chroot/etc/named/ I cannot find any documentation as what is indended to be placed in this subdirectory. my includes for named.conf? I am assuming the pki subdirectory is for DNSSEC related files, but I have not found any documentation indicating so. But then I have not plowed through DNSSEC documention in depth yet. ___ 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: chroot/etc/named/ directory?
On 02/13/2013 12:43 PM, Mike Hoskins (michoski) wrote: -Original Message- From: Robert Moskowitz r...@htt-consult.com Date: Wednesday, February 13, 2013 10:53 AM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: chroot/etc/named/ directory? I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in Centos 6.3. I have and will run bind chrooted and on my test setup I noticed a 'new' subdirectory in the chroot tree: /var/named/chroot/etc/named/ I cannot find any documentation as what is indended to be placed in this subdirectory. my includes for named.conf? I am assuming the pki subdirectory is for DNSSEC related files, but I have not found any documentation indicating so. But then I have not plowed through DNSSEC documention in depth yet. If you installed bind*-chroot, it will populate the /var/named/chroot hierarchy. I have been running chrooted since. Well probably when I switched from NT to Linux in '98. At first it was Whitehat, then Centos. I installed bind-chroot and though it built the /var/named/chroot tree, the only file is ~/etc/localtime, nothing else prepopulated. Well I DO have all my files from my current server to rsync over (over SSH so I don't have to actually run rsyncd), so it is no loss, just a question of where is everything. I seem to recall this tree in previous attempts to not be empty. Maybe they learned it is better for someone working here to do it all themselves... There are 'standard bind' files under /etc/nam* and /var/named to copy over if I choose (and find them more current than what I have from 2 years ago). It's not strictly required (though I would suggest it), but if you intend to run BIND chrooted /var/named/chroot is essentially /. Learned that some years ago. Familiar with how the tree is mounted. You'll have to place the usual things BIND needs to operate under that directory -- configs, zones, etc. Just seems that prior rpms came with a FEW files preset, like named.rfc1912.zones. But that was years ago and me brain is probably a little weak in the memory department. Assuming this came from the chroot RPM, you'll already have other essential pieces for chroot such as your null/random/zero devices. Yes. And there are a few under ~/dev/ Since you mention CentOS, you'll likely also want to pay attention to things like ROOTDIR in /etc/sysconfig/named. Came preset. I am assuming handled by the bind-chroot rpm. Having said all that, you might search the archives (SRPMS have been provided by community members) or other sources for a newer BIND while you're at it...9.8.2 isn't ancient, but also not technically up to date now. I am not up to building on my own and the few extra repos I work with (EPEL and rpmfusion) do not have a newer version all ready for Centos 6.3. How bad is it? :) I am personally waiting for 9.9.3 to leave beta, but 9.8.4-P1 probably makes sense for you today. This won't affect your chroot setup, just something worth considering since you're upgrading. I would want to find it already in an rpm. Once on the build it yourself carousel you are set there and I have other things I am suppose to be doing. ___ 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: chroot/etc/named/ directory?
On 02/13/2013 01:44 PM, Lightner, Jeff wrote: Haven't done it on RHEL/CentOS 6.x yet but in RHEL5 with the bind-chroot installed I've always had: /var/named/chroot as the jail for BIND. /var/named/chroot/etc = Location of global config files such as named.conf /var/named/chroot/var/named = Location of the zone files. These I am use to and have used them for years. I don't see a /var/named/chroot/etc/named in RHEL5 but then again that is based on BIND 9.3. RHEL6 is almost certainly based on a higher upstream version. Since CentOS is built from RHEL source it would have that higher version as well. Yes. I am going from Centos (RHEL) 5.5 to 6.3, so the new directory just has me wondering. I found it also as /etc/named/ so it is part of their base bind rpm, but no documentation on what they expected to be place there. Just here is something new and I want to know why so that I am not supprised. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Mike Hoskins (michoski) Sent: Wednesday, February 13, 2013 12:44 PM To: bind-users@lists.isc.org Subject: Re: chroot/etc/named/ directory? -Original Message- From: Robert Moskowitz r...@htt-consult.com Date: Wednesday, February 13, 2013 10:53 AM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: chroot/etc/named/ directory? I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in Centos 6.3. I have and will run bind chrooted and on my test setup I noticed a 'new' subdirectory in the chroot tree: /var/named/chroot/etc/named/ I cannot find any documentation as what is indended to be placed in this subdirectory. my includes for named.conf? I am assuming the pki subdirectory is for DNSSEC related files, but I have not found any documentation indicating so. But then I have not plowed through DNSSEC documention in depth yet. If you installed bind*-chroot, it will populate the /var/named/chroot hierarchy. It's not strictly required (though I would suggest it), but if you intend to run BIND chrooted /var/named/chroot is essentially /. You'll have to place the usual things BIND needs to operate under that directory -- configs, zones, etc. Assuming this came from the chroot RPM, you'll already have other essential pieces for chroot such as your null/random/zero devices. Since you mention CentOS, you'll likely also want to pay attention to things like ROOTDIR in /etc/sysconfig/named. Having said all that, you might search the archives (SRPMS have been provided by community members) or other sources for a newer BIND while you're at it...9.8.2 isn't ancient, but also not technically up to date now. I am personally waiting for 9.9.3 to leave beta, but 9.8.4-P1 probably makes sense for you today. This won't affect your chroot setup, just something worth considering since you're upgrading. ___ ___ 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: chroot/etc/named/ directory?
On 02/13/2013 03:40 PM, Mike Hoskins (michoski) wrote: -Original Message- From: Robert Moskowitz r...@htt-consult.com Date: Wednesday, February 13, 2013 2:15 PM To: Mike Hoskins micho...@cisco.com Cc: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: chroot/etc/named/ directory? Having said all that, you might search the archives (SRPMS have been provided by community members) or other sources for a newer BIND while you're at it...9.8.2 isn't ancient, but also not technically up to date now. I am not up to building on my own and the few extra repos I work with (EPEL and rpmfusion) do not have a newer version all ready for Centos 6.3. How bad is it? :) That's for you to decide: https://www.isc.org/software/bind/security/matrix So not SOOO bad, just Badenough (said the Moose to Rocky). Of course RHEL/CentOS make it somewhat hard to know what 9.8.2 means without reading change logs. They tend to select stable software versions at release time, then backport fixes with their own version numbering. So Red Hat's 9.8.2 likely has fixes for a lot of the ISC 9.8.2 issues...but you might want to confirm vs assume that. There is that. Just a check shows that #49 is fixed in what I have installed: https://rhn.redhat.com/errata/RHSA-2012-1268.html And #50: https://rhn.redhat.com/errata/RHSA-2012-1363.html So I would ASSuME that I can work with keeping my install current and will stay on top of things. At least for a while. And getting back to the start of this thread, until something shows up, I will just ignore that ~/etc/named/ directory thanks I would want to find it already in an rpm. Once on the build it yourself carousel you are set there and I have other things I am suppose to be doing. Understood. Happily, running secure DNS infra is one of the things that pays my mortgage. :-) ___ 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: Problems with include in acl file
Chris Thompson wrote:
On Oct 18 2009, Joseph S D Yao wrote:
On Sat, Oct 17, 2009 at 10:33:37PM -0400, Robert Moskowitz wrote:
I am trying to build up an environment where the user can maintain
custom files and leave the basic files alone.
So I have a named.acl that works, I add an include line:
acl hdanets {
192.168.1.0/24; // hda network
include custom.acl;
};
and get the error:
Starting named:
Error in named configuration:
named.acl:3: missing ';' before ''
...
Glancing through the 9.6 ARM https://www.isc.org/files/Bv9.6ARM.pdf,
it seems to me that include is a statement, and needs to be parsed
outside of any other statements, not inside a statement.
That's what it *says* ... but it is being economical with the truth!
Inside the
acl statement the parser would expect to see IP addresses, networks in
the ip.ad.dr.ess/xx format, keys with the name prepended by the keyword
key, and the names of other ACLs. When it encounters the word
include in this context, it parses it as the name of an ACL - after
which, the '' is out of place.
As long ago as BIND 9.2, you'll find this in the CHANGES file:
764. [func] Configuration files now allow include directives
in more places, such as inside the view
statement.
[RT #377, #728, #860]
Roughly, include can occur instead of a keyword in any list where all
list elements are introduced by keywords; e.g. view, options,
logging,
zone. But not acl because the elements there do not (in general)
start
with keywords.
Oh, fiddlesticks ;)'
This complicates matters. It would have made it very easy to bootstrap
into this process if this was supported.
For the whole truth, you need to look at lib/isccfg/namedconf.c and
lib/isccfg/parser.c and work out in exactly which cases cfg_parse_mapbody
in the latter gets called :-(
I am not much into reading c code. I never really programmed in c. Did
do some programming in b
So reading someone elses script and recommending changes has been
challenging enough!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
mySQL backend for BIND
I am NOT looking for one that automagically updates the various files. I am more than happy with one that builds the files, even including includes for 'non-supported types' (eg I am working with the HIP DNS records). I suppose I could design something, but then I would miss a lot. I did find: http://mysql-bind.sourceforge.net/, but this is 2 years without an update and it replaces the various conf files. I DO want mySQL as this is for an environment that already had a lot of other information (like Postfix, CourierMail, and Squirrelmail) in mySQL. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with include in acl file
Mark Andrews wrote:
In message 4adb44a5.2060...@htt-consult.com, Robert Moskowitz writes:
Chris Thompson wrote:
On Oct 18 2009, Joseph S D Yao wrote:
On Sat, Oct 17, 2009 at 10:33:37PM -0400, Robert Moskowitz wrote:
I am trying to build up an environment where the user can maintain
custom files and leave the basic files alone.
So I have a named.acl that works, I add an include line:
acl hdanets {
192.168.1.0/24; // hda network
include custom.acl;
};
and get the error:
Starting named:
Error in named configuration:
named.acl:3: missing ';' before ''
...
Glancing through the 9.6 ARM https://www.isc.org/files/Bv9.6ARM.pdf,
it seems to me that include is a statement, and needs to be parsed
outside of any other statements, not inside a statement.
That's what it *says* ... but it is being economical with the truth!
Inside the
acl statement the parser would expect to see IP addresses, networks in
the ip.ad.dr.ess/xx format, keys with the name prepended by the keyword
key, and the names of other ACLs. When it encounters the word
include in this context, it parses it as the name of an ACL - after
which, the '' is out of place.
As long ago as BIND 9.2, you'll find this in the CHANGES file:
764. [func] Configuration files now allow include directives
in more places, such as inside the view
statement.
[RT #377, #728, #860]
Roughly, include can occur instead of a keyword in any list where all
list elements are introduced by keywords; e.g. view, options,
logging,
zone. But not acl because the elements there do not (in general)
start
with keywords.
Oh, fiddlesticks ;)'
This complicates matters. It would have made it very easy to bootstrap
into this process if this was supported.
acl's can include other acls.
I'm having a hard time seeing why you need to include a file here.
include custom.acl; // defines acl customacl
acl hdanets {
92.168.1.0/24; // hda network
customacl;
};
Neat.
Though I solved the problem by having 2 includes in named.conf, for
named.acl and custom.acl. Then in the view, I listed two variables:
hdanets; customnets
So is the case of six of one, half-a-dozen of the other? That is they
are equal solutions to this situation?
As for why I am doing this, hdanets.acl is built by the system's script
that I have no control over. It will contain what the script has on my
internal networks. It only supports one network. But some users of
this system (like me) have a number of internal networks that we want to
be able to access this system, so custom.acl is outside of the
controlling script and can be maintained by an informed installer, like
me. There is also a custom-zone.conf and custom-n2a.zone and
custom-a2n.zone...
As we improve the system, there will be less need for these, but I
believe they will always be needed.
Oh, the system this is for is AMAHI.ORG.
For the whole truth, you need to look at lib/isccfg/namedconf.c and
lib/isccfg/parser.c and work out in exactly which cases cfg_parse_mapbody
in the latter gets called :-(
I am not much into reading c code. I never really programmed in c. Did
do some programming in b
So reading someone elses script and recommending changes has been
challenging enough!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Problems with include in acl file
I am trying to build up an environment where the user can maintain
custom files and leave the basic files alone.
So I have a named.acl that works, I add an include line:
acl hdanets {
192.168.1.0/24; // hda network
include custom.acl;
};
and get the error:
Starting named:
Error in named configuration:
named.acl:3: missing ';' before ''
[FAILED]
The file custom.acl exists and it contains:
192.168.2.0/24;
Perhaps includes are not allowed in .acl files?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Why isn't NSLOOKUP querying for sub-zone
Here is what NSLOOKUP is doing: # nslookup set type=any home.htt. Server: 208.83.67.148 Address:208.83.67.148#53 Non-authoritative answer: home.httnameserver = home.htt. Authoritative answers can be found from: home.httnameserver = home.htt. When I ask about htt. I get: htt. Server: 208.83.67.148 Address:208.83.67.148#53 htt origin = oqo3.htt-consult.com mail addr = rgm.htt-consult.com serial = 2009101305 refresh = 7200 retry = 1200 expire = 1209600 minimum = 7200 htt nameserver = onlo.htt-consult.com. htt nameserver = oqo3.htt. Name: htt Address: 192.168.1.35 htt has address 2607:f4b8:3:11:stuffdeleted note oqo3 is both oqo3.htt and oqo3.htt-consult.com. Further this server is a slave for htt. and in /named/slaves/bak.htt I have: $ORIGIN htt. homeNS hda.home $ORIGIN home.htt. hda A 192.168.128.2 So it 'knows' who is authoratative for home.htt. And when I grep named/data/named.run for 'home.hda' I come up empty (just checking cache for anything on home.htt). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with a BIND server
Barry Margolin wrote:
In article mailman.696.1255498841.14796.bind-us...@lists.isc.org,
Robert Moskowitz r...@htt-consult.com wrote:
Barry Margolin wrote:
In article mailman.693.1255466849.14796.bind-us...@lists.isc.org,
Robert Moskowitz r...@htt-consult.com wrote:
I have been running BIND here on my net for quite a few years time and
run 2 views on my main server, for internal and external users. I also
have a separate BIND server on a test bed that uses a test TLD of htt.
It has worked well for the past year.
Now I have installed an Amahi server (amahi.org) and it is running its
own BIND server with dynamic updates, as it is supporting NetBios
clients. My Amahi server is set up for home.htt and works for systems
on its subnet (it also runs DHCPD). I want access to the various Amahi
apps to other systems here so I first:
Set up my main server to be a slave for my test htt domain in its
internal view.
That is working well and I can get all the DNS information supported
there (both hosts in htt and its sub-zone of mobile.htt). Fine so far.
Then I added a couple records to the zone file in htt to delegate home.htt:
home.htt. IN NS amahi.home.htt.
amahi.home.htt. IN A 192.168.1.2
And nothing.
I am NOT getting any information on the home.htt. sub-zone. If I run
'nslookup - 192.168.1.2' I get all the information in the DNS, but
neither of my internal BIND servers are getting information. Almost as
if the Amahi server is not honoring requests from other BIND servers or
perhaps not on its net.
Are you sure they're sending the queries to it? Have you done a packet
capture to see what's being sent?
Well I did some more testing. Here are some results when host is run on
my main DNS server which is a slave server for htt.
Can you post the named.conf file for the server you're querying, not the
server that hosts the subdomain?
In pieces. First named.conf:
cat named.conf
//
include /etc/named.acl;
options
{
/* make named use port 53 for the source of all queries, to allow
* firewalls to block all ports except 53:
*/
query-sourceport 53;
query-source-v6 port 53;
listen-on-v6 {any; };
// Put files that named is allowed to write in the data/ directory:
directory /var/named; // the default
dump-file data/cache_dump.db;
statistics-file data/named_stats.txt;
memstatistics-file data/named_mem_stats.txt;
};
logging
{
channel default_debug {
file data/named.run;
severity dynamic;
};
};
//
view internal
{
match-clients { httnets; };
match-destinations { httnets; };
recursion yes;
//notify no;# disable AA notifies?
// all views must contain the root hints zone:
include /etc/named.root.hints;
include /etc/named.rfc1912.zones;
// you should not serve your rfc1912 names to non-localhost clients.
// These are your authoritative internal zones, and would probably
// also be included in the localhost_resolver view above :
include /etc/named.internal;
};
/*key ddns_key
*{
* algorithm hmac-md5;
* secret use /usr/sbin/dns-keygen to generate TSIG keys;
*};
*/
viewexternal
{
match-clients { any; };
match-destinations { any; };
recursion no;
// you'd probably want to deny recursion to external clients, so
you don't
// end up providing free DNS service to all takers
// all views must contain the root hints zone:
include /etc/named.root.hints;
// These are your authoritative external zones, and would probably
// contain entries for just your web and mail servers:
include /etc/named.external;
};
include /etc/rndc.key;
Now comes named.internal (I am ASSUMING that you don't need named.acl or
named.external):
# cat named.internal
zone htt-consult.com {
type master;
file httin-consult.com.zone;
};
zone 128-26.67.83.208.in-addr.arpa {
type master;
file 128-26.67.83.208.in-addr.arpa.zone;
};
zone 3.0.0.0.8.b.4.f.7.0.6.2.ip6.arpa {
type master;
file 3.0.0.0.8.b.4.f.7.0.6.2.ip6.arpa.zone;
};
zone labs.htt-consult.com {
type master;
file labs.htt-consult.com.hosts;
};
zone mobile.htt-consult.com {
type master;
file mobile.htt-consult.com.hosts;
};
zone test.htt-consult.com {
type master;
file test.htt-consult.com.hosts;
};
zone 128.168.192.in-addr.arpa {
type master;
file 128.168.192.in-addr.arpa.zone;
};
zone 0-24.128.168.192.in-addr.arpa
SOLVED -- Re: Problems with a BIND server
SOLVED!!!
Problem was with the DNS server for home.htt. The zone files there are
built from scripts from a database, and there are problems with the SOA,
NS, and MX records. I will have to submit a bug.
In all cases, instead of the host FQDN, there was only the domain. So I
editted the zone files, restarted BIND on all the servers (I am sure
there was an easier way, but I chose the big hammer),
And now things are working right!
ARGH!!! I looked at those files a dozen times. But since they are
generated by a script, I guess I never really thought about some of the
content. Things work well enough within the domain for its purposes,
but broken outside of that...
Robert Moskowitz wrote:
I have been running BIND here on my net for quite a few years time and
run 2 views on my main server, for internal and external users. I
also have a separate BIND server on a test bed that uses a test TLD of
htt. It has worked well for the past year.
Now I have installed an Amahi server (amahi.org) and it is running its
own BIND server with dynamic updates, as it is supporting NetBios
clients. My Amahi server is set up for home.htt and works for systems
on its subnet (it also runs DHCPD). I want access to the various
Amahi apps to other systems here so I first:
Set up my main server to be a slave for my test htt domain in its
internal view.
That is working well and I can get all the DNS information supported
there (both hosts in htt and its sub-zone of mobile.htt). Fine so far.
Then I added a couple records to the zone file in htt to delegate
home.htt:
home.htt. IN NS amahi.home.htt.
amahi.home.htt. IN A 192.168.1.2
And nothing.
I am NOT getting any information on the home.htt. sub-zone. If I run
'nslookup - 192.168.1.2' I get all the information in the DNS, but
neither of my internal BIND servers are getting information. Almost
as if the Amahi server is not honoring requests from other BIND
servers or perhaps not on its net.
Here are the named.conf and zone files:
# automatically generated file by hdactl
options {
listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
forward only;
forwarders { 208.67.222.222; 208.67.220.220; };
listen-on port 53 { 192.168.1.2; 127.0.0.1; };
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
key ddnskey {
algorithm hmac-md5;
secret --;
};
zone home.htt IN {
type master;
notify no;
file dynamic/hda-n2a.conf;
allow-update { key ddnskey; };
check-names ignore;
};
zone 1.168.192.in-addr.arpa IN {
type master;
notify no;
file dynamic/hda-a2n.conf;
allow-update { key ddnskey; };
check-names ignore;
};
and dynamic/hda-n2a.conf:
$TTL86400
@ IN SOA home.htt. root.home.htt. (
0909130103 ; Serial
28800 ; Refresh
14400 ; Retry
360 ; Expire
86400 ) ; Minimum
IN NS home.htt.
IN MX 10 home.htt.
* IN MX 10 home.htt.
h001A 192.168.1.1
.
.
.
hda A 192.168.1.2
search A 192.168.1.2
setup A 192.168.1.2
calendarA 192.168.1.2
helpA 192.168.1.2
wikiA 192.168.1.2
So any tips on what to look for to get this working?
I shot the day digging, and I can do things with BIND, but I am not
all that skilled...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: SOLVED -- Re: Problems with a BIND server
Barry Margolin wrote: In article mailman.702.126893.14796.bind-us...@lists.isc.org, Robert Moskowitz r...@htt-consult.com wrote: SOLVED!!! Problem was with the DNS server for home.htt. The zone files there are built from scripts from a database, and there are problems with the SOA, NS, and MX records. I will have to submit a bug. I don't get it. I thought things worked correctly when you queried the DNS server for home.htt, and the problem was only when you queried the htt server. Truly weird. I sent in a bug report to the amahi developers, and then I had to actually make the fixes to the script. Turned out not to be too hard. At least for this problem. There are others that are not as broken, but still problems... When I queried from home.htt (really hda.home.htt), it appears that it does not matter that the SOA and NS are wrong and do not point to an IP address. It is authoratative for the zone and just reports from its cache. Likewise a client that uses it directly as its nameserver, would never be the wiser of the problem. Only when another nameserver did the lookup. If you look at that TCPDUMP use see the first lookup of say, wiki.home.htt which returns the A record. Then a lookup of home.htt which fails. From this point on, ANY lookup of any host in home.htt fails completely. The cache is 'ruined?' with that failed lookup of the NS from hda.home.htt. Wierd, but then who puts an SOA and NS entry that does not have an A record? That is the case here... It could also been fixed simply with an A record for home.htt which many sites do so that http://home.htt would work. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Problems with a BIND server
I have been running BIND here on my net for quite a few years time and
run 2 views on my main server, for internal and external users. I also
have a separate BIND server on a test bed that uses a test TLD of htt.
It has worked well for the past year.
Now I have installed an Amahi server (amahi.org) and it is running its
own BIND server with dynamic updates, as it is supporting NetBios
clients. My Amahi server is set up for home.htt and works for systems
on its subnet (it also runs DHCPD). I want access to the various Amahi
apps to other systems here so I first:
Set up my main server to be a slave for my test htt domain in its
internal view.
That is working well and I can get all the DNS information supported
there (both hosts in htt and its sub-zone of mobile.htt). Fine so far.
Then I added a couple records to the zone file in htt to delegate home.htt:
home.htt. IN NS amahi.home.htt.
amahi.home.htt. IN A 192.168.1.2
And nothing.
I am NOT getting any information on the home.htt. sub-zone. If I run
'nslookup - 192.168.1.2' I get all the information in the DNS, but
neither of my internal BIND servers are getting information. Almost as
if the Amahi server is not honoring requests from other BIND servers or
perhaps not on its net.
Here are the named.conf and zone files:
# automatically generated file by hdactl
options {
listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
forward only;
forwarders { 208.67.222.222; 208.67.220.220; };
listen-on port 53 { 192.168.1.2; 127.0.0.1; };
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
key ddnskey {
algorithm hmac-md5;
secret --;
};
zone home.htt IN {
type master;
notify no;
file dynamic/hda-n2a.conf;
allow-update { key ddnskey; };
check-names ignore;
};
zone 1.168.192.in-addr.arpa IN {
type master;
notify no;
file dynamic/hda-a2n.conf;
allow-update { key ddnskey; };
check-names ignore;
};
and dynamic/hda-n2a.conf:
$TTL86400
@ IN SOA home.htt. root.home.htt. (
0909130103 ; Serial
28800 ; Refresh
14400 ; Retry
360 ; Expire
86400 ) ; Minimum
IN NS home.htt.
IN MX 10 home.htt.
* IN MX 10 home.htt.
h001A 192.168.1.1
.
.
.
hda A 192.168.1.2
search A 192.168.1.2
setup A 192.168.1.2
calendarA 192.168.1.2
helpA 192.168.1.2
wikiA 192.168.1.2
So any tips on what to look for to get this working?
I shot the day digging, and I can do things with BIND, but I am not all
that skilled...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with a BIND server
Barry Margolin wrote:
In article mailman.693.1255466849.14796.bind-us...@lists.isc.org,
Robert Moskowitz r...@htt-consult.com wrote:
I have been running BIND here on my net for quite a few years time and
run 2 views on my main server, for internal and external users. I also
have a separate BIND server on a test bed that uses a test TLD of htt.
It has worked well for the past year.
Now I have installed an Amahi server (amahi.org) and it is running its
own BIND server with dynamic updates, as it is supporting NetBios
clients. My Amahi server is set up for home.htt and works for systems
on its subnet (it also runs DHCPD). I want access to the various Amahi
apps to other systems here so I first:
Set up my main server to be a slave for my test htt domain in its
internal view.
That is working well and I can get all the DNS information supported
there (both hosts in htt and its sub-zone of mobile.htt). Fine so far.
Then I added a couple records to the zone file in htt to delegate home.htt:
home.htt. IN NS amahi.home.htt.
amahi.home.htt. IN A 192.168.1.2
And nothing.
I am NOT getting any information on the home.htt. sub-zone. If I run
'nslookup - 192.168.1.2' I get all the information in the DNS, but
neither of my internal BIND servers are getting information. Almost as
if the Amahi server is not honoring requests from other BIND servers or
perhaps not on its net.
Are you sure they're sending the queries to it? Have you done a packet
capture to see what's being sent?
Well I did some more testing. Here are some results when host is run on
my main DNS server which is a slave server for htt.
# host wiki.home.htt
wiki.home.htt has address 192.168.1.2
Host wiki.home.htt not found: 2(SERVFAIL)
Host wiki.home.htt not found: 2(SERVFAIL)
# host search.home.htt
Host search.home.htt not found: 2(SERVFAIL)
The later should also have responded with the same IP address. And why
the two servfails? Here is records from a TCPDUMP of the first host
command:
# grep 1.2 trace.1
23:18:24.142341 IP 208.83.67.148.domain 192.168.1.2.domain: 9401
[1au] A? wiki.home.htt. (42)
23:18:24.144246 IP 192.168.1.2.domain 208.83.67.148.domain: 9401*-
1/1/1 A 192.168.128.2 (72)
23:18:24.149357 IP 208.83.67.148.domain 192.168.1.2.domain: 11640%
[1au] A? home.htt. (37)
23:18:24.149786 IP 208.83.67.148.domain 192.168.1.2.domain: 46350%
[1au] ? home.htt. (37)
23:18:24.150804 IP 192.168.1.2.domain 208.83.67.148.domain: 11640*-
0/1/1 (78)
23:18:26.152190 IP 208.83.67.148.domain 192.168.1.2.domain: 11257%
[1au] ? home.htt. (37)
23:18:26.152635 IP 208.83.67.148.domain 192.168.1.2.domain: 22505%
[1au] ? hda.home.htt. (41)
23:18:26.153864 IP 192.168.1.2.domain 208.83.67.148.domain: 11257*-
0/1/1 (78)
23:18:28.154700 IP 208.83.67.148.domain 192.168.1.2.domain: 49416%
[1au] ? hda.home.htt. (41)
23:18:28.156390 IP 192.168.1.2.domain 208.83.67.148.domain: 49416*-
0/1/1 (82)
And for the second command there were NO records to 192.168.1.2
And on my notebook that uses 208.83.67.148 as its only nameserver, 'host
search.home.htt' has the following dump:
# tcpdump -n -i eth1 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
01:28:34.615393 IP 208.83.67.158.35220 208.83.67.148.domain: 4544+ A?
search.home.htt. (33)
01:28:34.618864 IP 208.83.67.148.domain 208.83.67.158.35220: 4544
ServFail 0/0/0 (33)
So I am quite perplexed.
Here are the named.conf and zone files:
# automatically generated file by hdactl
options {
listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
forward only;
forwarders { 208.67.222.222; 208.67.220.220; };
listen-on port 53 { 192.168.1.2; 127.0.0.1; };
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
key ddnskey {
algorithm hmac-md5;
secret --;
};
zone home.htt IN {
type master;
notify no;
file dynamic/hda-n2a.conf;
allow-update { key ddnskey; };
check-names ignore;
};
zone 1.168.192.in-addr.arpa IN {
type master;
notify no;
file dynamic/hda-a2n.conf;
allow-update { key ddnskey; };
check-names ignore;
};
and dynamic/hda-n2a.conf:
$TTL86400
@ IN SOA home.htt. root.home.htt. (
0909130103 ; Serial
28800 ; Refresh
14400 ; Retry
360 ; Expire
86400 ) ; Minimum
IN NS home.htt.
IN MX 10 home.htt.
* IN MX 10 home.htt.
h001A 192.168.1.1
.
.
.
hda A 192.168.1.2
search
