compile 9.6.0p1 etc empty
when I compile bind 9.6.0p1 I have nothing in etc
mkdir /test
. /configure - prefix = test
make
make install
cd /test/etc is empty
an explanation?
I forget something?
thanks in advance
--
- GanGan -
www.system-linux.eu
(">
/\
V_V
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS lookups getting blocked , cant trace where is the block
On Fri, Jan 16, 2009 at 11:44:06AM +0530, ram wrote a message of 44 lines which said: > [r...@smtpout1 ~]# dig @localhost bsnl.in > ; <<>> DiG 9.3.3rc2 <<>> @localhost bsnl.in > ; (1 server found) > ;; global options: printcmd > ;; connection timed out; no servers could be reached Since you are root, you can examine BIND's journal on smtpout1, you will probably find a lot of things. After that, you can fire tcpdump: tcpdump -vvv -n udp and port 53 and host 218.248.240.178 And you'll get a lot of information, too. > Ofcourse I checked that my local bind is working fine, since it can > resolve almost all other domains Yes, but it may do bad things (such as sending requests from port 53) that are accepted *almost* everywhere but not at bsnl.in. Also, it can do correct things (such as using extensions like EDNS0) that are accepted *almost* everywhere but not at bsnl.in (bad example since 218.248.240.178 seems happy with EDNS0). > So where is the DNS request getting blocked. Use BIND log and tcpdump ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Reverse DNS with delegation
Hello,
I'm encountering a very strange behavior with our dns server since we
moved to an other data center with *reverse request only.*
Before, we had authority on a subnet xxx.yyy.zzz.0/24 but now our
authority is only for the network 94.103.140.0/28... our provider has
updated its upstream to delegate this subnet and the translation is
working fine (x.140.103.94.in-addr.arpa translate to
x.0-28.140.103.94.in-addr.arpa) and I think I've made the good changes
on our DNS server but our dns is responding "no answer" when trying to
dig an existing entry and "nxdomain" when there is no entry (which is
correct)...
/*zone definition :*/
zone "0-28.140.103.94.in-addr.arpa" {
type master;
allow-query { any; };
allow-transfer { xxx };
file "/etc/bind/zones/reverse.conf";
};
/*/etc/bind/zones/reverse.conf :*/
$ORIGIN .
$TTL 86400
0-28.140.103.94.in-addr.arpaIN SOA ns1.fimasys.com.
support.fimasys.com. (
2009011503
86400
3600
604800
86400
)
$ORIGIN 0-28.140.103.94.in-addr.arpa.
@ IN NS ns1.fimasys.com.
@ IN NS ns2.fimasys.com.
@ IN NS ns3.fimasys.com.
@ IN NS ns4.fimasys.com.
4IN PTR athena.fimasys.com.
[there is other entries of course, but athena is the ns1 and
94.103.140.6 has no PTR record]
/*Dig result with our provider dns :*/
dig 4.140.103.94.in-addr.arpa. @ns1.mit-datacenter.net
; <<>> DiG 9.3.4-P1.1 <<>> 4.140.103.94.in-addr.arpa.
@ns1.mit-datacenter.net
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35202
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;4.140.103.94.in-addr.arpa. IN A
;; ANSWER SECTION:
4.140.103.94.in-addr.arpa. 86400 IN CNAME
4.0-28.140.103.94.in-addr.arpa.
;; AUTHORITY SECTION:
140.103.94.in-addr.arpa. 259200 IN NS ns1.mit-datacenter.net.
140.103.94.in-addr.arpa. 259200 IN NS ns2.mit-datacenter.net.
;; ADDITIONAL SECTION:
ns1.mit-datacenter.net. 3600IN A 94.103.128.65
ns2.mit-datacenter.net. 3600IN A 88.191.203.15
;; Query time: 24 msec
;; SERVER: 94.103.128.65#53(94.103.128.65)
;; WHEN: Fri Jan 16 12:11:25 2009
;; MSG SIZE rcvd: 150
/*Dig result with our DNS on an existing entry :*/
dig 4.0-28.140.103.94.in-addr.arpa. @ns1.fimasys.com
; <<>> DiG 9.3.4-P1.1 <<>> 4.0-28.140.103.94.in-addr.arpa. @ns1.fimasys.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34891
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;4.0-28.140.103.94.in-addr.arpa.IN A
;; AUTHORITY SECTION:
0-28.140.103.94.in-addr.arpa. 86400 IN SOA ns1.fimasys.com.
support.fimasys.com. 2009011503 86400 3600 604800 86400
;; Query time: 23 msec
;; SERVER: 94.103.140.4#53(94.103.140.4)
;; WHEN: Fri Jan 16 12:17:33 2009
;; MSG SIZE rcvd: 107
/*Dig result with our DNS on an unused entry :*/
dig 6.0-28.140.103.94.in-addr.arpa. @ns1.fimasys.com
; <<>> DiG 9.3.4-P1.1 <<>> 6.0-28.140.103.94.in-addr.arpa. @ns1.fimasys.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27692
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;6.0-28.140.103.94.in-addr.arpa.IN A
;; AUTHORITY SECTION:
0-28.140.103.94.in-addr.arpa. 86400 IN SOA ns1.fimasys.com.
support.fimasys.com. 2009011503 86400 3600 604800 86400
;; Query time: 24 msec
;; SERVER: 94.103.140.4#53(94.103.140.4)
;; WHEN: Fri Jan 16 12:25:31 2009
;; MSG SIZE rcvd: 107
All other zones are working just fine... only the reverse is wrong. The
version of bind is 9.2.4, running on debian.
Regards,
Jeremie Grauer
Sysadmin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse DNS with delegation
On Fri, Jan 16, 2009 at 12:27:54PM +0100, Jérémie Grauer wrote a message of 282 lines which said: > I'm encountering a very strange behavior with our dns server No, it is dig behavior. You never indicate the Resource Record type so dig picks "A" (IPv4 address). If you indicate "ANY" or "PTR", it will work. Or just use the -x option: % dig -x 94.103.140.4 ... ;; QUESTION SECTION: ;4.140.103.94.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.140.103.94.in-addr.arpa. 86400 IN CNAME 4.0-28.140.103.94.in-addr.arpa. 4.0-28.140.103.94.in-addr.arpa. 86322 IN PTRathena.fimasys.com. > All other zones are working just fine... only the reverse is wrong. The > version of bind is 9.2.4, running on debian. BTW, this is extremely old. The version in debian "stable" is 9.3.4 (with various Debian patches). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL issues
Hello, Has the "max-cache-size" setting in named.conf been considered? If not, note that in early releases of 9.5.x max-cache-size is 32M by default instead of unlimited as in 9.4.x >From the CHANGES file with the bind-9.5.0-P2 source: ""max-cache-size" defaults to 32M" Using: max-cache-size 0 ; will restore previous behavior (unlimited). The ultimate setting would need to be considered for the environment BIND is running in. FWIW, we use max-cache-size 0 ; without issue. You can search this list archives for max-cache-size for previous discussions on this. Thanks. - Original Message From: Frank Bulk To: bind-users@lists.isc.org Sent: Thursday, January 15, 2009 6:57:10 PM Subject: SERVFAIL issues http://marc.info/?l=bind-users&m=122239920822324&w=2 http://marc.info/?l=bind-users&m=122243068905656&w=2 We upgraded to 9.5.0-P1 when the Kaminsky DNS vulnerability was announced and have had intermittent issues with SERVFAIL problems for some DSL modems that don't properly fail over to a secondary DNS server. A packet capture showed that certain domains would result in a SERVFAIL, and once that domain was identified, if we did a dig against it we had the same result. We've had to stop and start the named service about half a dozen times this fall to resolve the issue. We upgraded to 9.5.0-P2 in early November, hoping that this issue would be resolved. But today we experienced the problem again. A customer couldn't query a site, although everything seemed correct. I captured all their traffic and the trace showed that the DNS server was issuing a SERVFAIL. I stopped and then started named and immediately all was well. Since we sometimes reload named when adding/modifying domains, or at other times use rndc, I'm not sure if that "cleared" things up such that this is the first time I recall having this problem in 2 months. Is this intermittent SERVFAIL issue resolved in 9.5.1-P1? Frank ___ 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: Multiple PTR records
> On Jan 15, 2009, at 6:33 AM, Halassy Zoltán wrote: > >I don't want to break forward <-> reverse mapping. > > > >www.example.com. A 1.2.3.4 > >mail.example.com. A 1.2.3.4 > >4.3.2.1.in-addr.arpa. PTR www.example.com. > >4.3.2.1.in-addr.arpa. PTR mail.example.com. > >Would this one break anything? Or anyone else have a better tip how > >could i handle this situation? Multiple PTRs in this case is really > >an issue? > On 15.01.09 10:19, Chris Buxton wrote: > Yes, it is an issue. Remove this record: > > 4.3.2.1.in-addr.arpa. PTR www.example.com. > > Your web server doesn't need a PTR record. > >The main thing i don't want to break forward <-> reverse symmetry > >cause there are some sanity checks about this (like in spamfiltering). > > Right, your mail server ought to have a PTR record. Your web server, > however, does not need it. Actually, it doesn't matter which PTR record will remain, unless there will be any SPF record pointing to it. And even a mail server does not need PTR record, if it only accepts mail, but does not send. The valid PTR is important when sending mail - many servers will refuse connections from IP's without valid PTR and A records. The contents of the record is not that much important (unless using SPF), although some servers refuse mail from generic-looking names (e.g. a-b-c-d.anything.example) -- 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. How does cat play with mouse? cat /dev/mouse ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: compile 9.6.0p1 etc empty
On Fri, 16 Jan 2009, GanGan wrote: > when I compile bind 9.6.0p1 I have nothing in etc BIND doesn't install a configuration file. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Unable to perform nslookup of local domains
We are having a problem doing an nslookup locally from our BIND DNS Servers (Master & Secondary) for our own domains. However we can run nslookup on other domains (ie yahoo, google) with no problems. Even if we stop iptables we still get the same error. We see no errors when BIND starts. Below is the command output. Does this have anything to do with /etc/hosts or /etc/resolv.conf files? We've verified permissions on the directory/files. nslookup www.osmre.gov ;; Got SERVFAIL reply from 192.243.130.42, trying next server Server: 192.243.160.18 Address:192.243.160.18#53 ** server can't find www.osmre.gov: SERVFAIL Thanks for any help provided. Mark ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dns query process
Hi all This is result of tracing www.google.com by dig 9.5.0 ; <<>> DiG 9.5.0-P1 <<>> +trace www.google.com ;; global options: printcmd . 9398IN NS E.ROOT-SERVERS.NET. . 9398IN NS G.ROOT-SERVERS.NET. . 9398IN NS K.ROOT-SERVERS.NET. . 9398IN NS L.ROOT-SERVERS.NET. . 9398IN NS A.ROOT-SERVERS.NET. . 9398IN NS J.ROOT-SERVERS.NET. . 9398IN NS B.ROOT-SERVERS.NET. . 9398IN NS I.ROOT-SERVERS.NET. . 9398IN NS D.ROOT-SERVERS.NET. . 9398IN NS F.ROOT-SERVERS.NET. . 9398IN NS M.ROOT-SERVERS.NET. . 9398IN NS C.ROOT-SERVERS.NET. . 9398IN NS H.ROOT-SERVERS.NET. ;; Received 272 bytes from 10.10.10.101#53(10.10.10.101) in 0 ms com.172800 IN NS a.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. ;; Received 492 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 273 ms google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 168 bytes from 192.41.162.30#53(l.gtld-servers.net) in 296 ms www.google.com. 604800 IN CNAME www.l.google.com. l.google.com. 86400 IN NS c.l.google.com. l.google.com. 86400 IN NS b.l.google.com. l.google.com. 86400 IN NS a.l.google.com. l.google.com. 86400 IN NS g.l.google.com. l.google.com. 86400 IN NS e.l.google.com. l.google.com. 86400 IN NS d.l.google.com. l.google.com. 86400 IN NS f.l.google.com. ;; Received 276 bytes from 216.239.34.10#53(ns2.google.com) in 349 ms Here is result of querying ns record from ns1.google.com > google.com Server: [216.239.32.10] Address: 216.239.32.10 Got answer: HEADER: opcode = QUERY, id = 6, rcode = NOERROR header flags: response, auth. answer, want recursion questions = 1, answers = 4, authority records = 0, additional = 4 QUESTIONS: google.com, type = NS, class = IN ANSWERS: -> google.com nameserver = ns2.google.com ttl = 345600 (4 days) -> google.com nameserver = ns3.google.com ttl = 345600 (4 days) -> google.com nameserver = ns1.google.com ttl = 345600 (4 days) -> google.com nameserver = ns4.google.com ttl = 345600 (4 days) ADDITIONAL RECORDS: -> ns1.google.com internet address = 216.239.32.10 ttl = 345600 (4 days) -> ns2.google.com internet address = 216.239.34.10 ttl = 345600 (4 days) -> ns3.google.com internet address = 216.239.36.10 ttl = 345600 (4 days) -> ns4.google.com internet address = 216.239.38.10 ttl = 345600 (4 days) google.com nameserver = ns2.google.com ttl = 345600 (4 days) google.com nameserver = ns3.google.com ttl = 345600 (4 days) google.com nameserver = ns1.google.com ttl = 345600 (4 days) google.com nameserver = ns4.google.com ttl = 345600 (4 days) ns1.google.com internet address = 216.239.32.10 ttl = 345600 (4 days) ns2.google.com internet address = 216.239.34.10 ttl = 345600 (4 days) ns3.google.com internet address = 216.239.36.10 ttl = 345600 (4 days) ns4.google.com internet address = 216.239.38.10 ttl = 345600 (4 days) > As shown above ,the first result from dig show that ns1.google.com record in com. has ttl= 172800 but the second result from querying one of google.comzone authorize which in is case is ns1.google.com show that ttl=3
Re: dns query process
Since they may have cached the NS records at any time, it's just a maximum of 345600. Once a device follows the delegation from the .com authority and queries ns1.google.com directly, the NS records in the cache that were learned from the .com level servers are overwritten with what was learned from ns1.google.com. The NS records from the TLD authority typically only exist within a cache for a brief period until overwritten by first query response from the actual authority. On Fri, Jan 16, 2009 at 10:56 AM, jittinan suwanrueangsri < jittin...@gmail.com> wrote: > Hi all > > This is result of tracing www.google.com by dig 9.5.0 > > ; <<>> DiG 9.5.0-P1 <<>> +trace www.google.com > ;; global options: printcmd > . 9398IN NS E.ROOT-SERVERS.NET. > . 9398IN NS G.ROOT-SERVERS.NET. > . 9398IN NS K.ROOT-SERVERS.NET. > . 9398IN NS L.ROOT-SERVERS.NET. > . 9398IN NS A.ROOT-SERVERS.NET. > . 9398IN NS J.ROOT-SERVERS.NET. > . 9398IN NS B.ROOT-SERVERS.NET. > . 9398IN NS I.ROOT-SERVERS.NET. > . 9398IN NS D.ROOT-SERVERS.NET. > . 9398IN NS F.ROOT-SERVERS.NET. > . 9398IN NS M.ROOT-SERVERS.NET. > . 9398IN NS C.ROOT-SERVERS.NET. > . 9398IN NS H.ROOT-SERVERS.NET. > ;; Received 272 bytes from 10.10.10.101#53(10.10.10.101) in 0 ms > com.172800 IN NS a.gtld-servers.net. > com.172800 IN NS b.gtld-servers.net. > com.172800 IN NS c.gtld-servers.net. > com.172800 IN NS d.gtld-servers.net. > com.172800 IN NS e.gtld-servers.net. > com.172800 IN NS f.gtld-servers.net. > com.172800 IN NS g.gtld-servers.net. > com.172800 IN NS h.gtld-servers.net. > com.172800 IN NS i.gtld-servers.net. > com.172800 IN NS j.gtld-servers.net. > com.172800 IN NS k.gtld-servers.net. > com.172800 IN NS l.gtld-servers.net. > com.172800 IN NS m.gtld-servers.net. > ;; Received 492 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 273 ms > google.com. 172800 IN NS ns1.google.com. > google.com. 172800 IN NS ns2.google.com. > google.com. 172800 IN NS ns3.google.com. > google.com. 172800 IN NS ns4.google.com. > ;; Received 168 bytes from 192.41.162.30#53(l.gtld-servers.net) in 296 ms > www.google.com. 604800 IN CNAME www.l.google.com. > l.google.com. 86400 IN NS c.l.google.com. > l.google.com. 86400 IN NS b.l.google.com. > l.google.com. 86400 IN NS a.l.google.com. > l.google.com. 86400 IN NS g.l.google.com. > l.google.com. 86400 IN NS e.l.google.com. > l.google.com. 86400 IN NS d.l.google.com. > l.google.com. 86400 IN NS f.l.google.com. > ;; Received 276 bytes from 216.239.34.10#53(ns2.google.com) in 349 ms > > Here is result of querying ns record from ns1.google.com > > > > google.com > Server: [216.239.32.10] > Address: 216.239.32.10 > > Got answer: > HEADER: > opcode = QUERY, id = 6, rcode = NOERROR > header flags: response, auth. answer, want recursion > questions = 1, answers = 4, authority records = 0, additional = > 4 > QUESTIONS: > google.com, type = NS, class = IN > ANSWERS: > -> google.com > nameserver = ns2.google.com > ttl = 345600 (4 days) > -> google.com > nameserver = ns3.google.com > ttl = 345600 (4 days) > -> google.com > nameserver = ns1.google.com > ttl = 345600 (4 days) > -> google.com > nameserver = ns4.google.com > ttl = 345600 (4 days) > ADDITIONAL RECORDS: > -> ns1.google.com > internet address = 216.239.32.10 > ttl = 345600 (4 days) > -> ns2.google.com > internet address = 216.239.34.10 > ttl = 345600 (4 days) > -> ns3.google.com > internet address = 216.239.36.10 > ttl = 345600 (4 days) > -> ns4.google.com > internet address = 216.239.38.10 > ttl = 345600 (4 days) > > google.com > nameserver = ns2.google.com > ttl = 345600 (4 days) > google.com > nameserver = ns3.go
DNS spoofing
Hello, we need to deliberately point some of our DNS clients to a host with a different IP. Basically, when a client on a certain subnet asks for a host.somedomain.comthey should get an address for host.mydomain.com. All other DNS information for somedomain.com must be valid for all of my clients. I have no control over somedomain.com DNS but I have full controll over our DNS servers. What is the best way of doing this with bind? What are other ways of doing this (eg modify local resolvers)? Any ideas are greatly appreciated. -- Rob ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple PTR records
On Jan 16, 2009, at 7:13 AM, Matus UHLAR - fantomas wrote: Actually, it doesn't matter which PTR record will remain, unless there will be any SPF record pointing to it. That is a common misconception. I have seen mail bounced because of a mismatch between SMTP greeting name and PTR record name. It's not as common as the simple "is there any PTR record" check, but it does happen. The SMTP greeting name should also have an A record that resolves back to the address used as the source address of the connection. I once saw an SMTP server used to send mail from several unrelated domains, where each one was sent out through a different address. The mail server used the same name in the SMTP greeting regardless of which domain it was sending for, and this caused problems for all of the other domains. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to perform nslookup of local domains
Looks like your DNS servers 192.243.130.42 and 192.243.160.18 are not responding to DNS queries (thus the SERFAIL message). When trying this from my house, this is what I get: First, get the name servers for your domain osmre.gov from the DNS server at 4.2.2.2: $ dig @4.2.2.2 osmre.gov ns ; <<>> DiG 9.4.2-P2 <<>> @4.2.2.2 osmre.gov ns ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16977 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;osmre.gov. IN NS ;; ANSWER SECTION: osmre.gov. 28395 IN NS gb.osmre.gov. osmre.gov. 28395 IN NS nomad.osmre.gov. ;; Query time: 22 msec ;; SERVER: 4.2.2.2#53(4.2.2.2) ;; WHEN: Fri Jan 16 10:03:40 2009 ;; MSG SIZE rcvd: 64 Next, try to query each one of the two name servers about www.osmre.gov: (trying nomad.osmre.gov first, this failed): $ dig @nomad.osmre.gov www.osmre.gov. a ; <<>> DiG 9.4.2-P2 <<>> @nomad.osmre.gov www.osmre.gov. a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50624 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.osmre.gov. IN A ;; Query time: 103 msec ;; SERVER: 192.243.130.42#53(192.243.130.42) ;; WHEN: Fri Jan 16 10:05:06 2009 ;; MSG SIZE rcvd: 31 Try the next name server gb.osmre.gov, this gave an answer: $ dig @gb.osmre.gov www.osmre.gov. a ; <<>> DiG 9.4.2-P2 <<>> @gb.osmre.gov www.osmre.gov. a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17158 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.osmre.gov. IN A ;; ANSWER SECTION: www.osmre.gov. 28800 IN CNAME ismhdqf07a.osmre.gov. ismhdqf07a.osmre.gov. 28800 IN A 192.243.130.2 ;; AUTHORITY SECTION: osmre.gov. 28800 IN NS nomad.osmre.gov. osmre.gov. 28800 IN NS gb.osmre.gov. ;; ADDITIONAL SECTION: gb.osmre.gov. 28800 IN A 192.243.160.18 nomad.osmre.gov.28800 IN A 192.243.130.42 ;; Query time: 82 msec ;; SERVER: 192.243.160.18#53(192.243.160.18) ;; WHEN: Fri Jan 16 10:05:46 2009 ;; MSG SIZE rcvd: 141 >From the above results, it looks like your name server nomad.osmre.gov (192.243.130.42) is not functioning correctly, but the server gb.osmre.gov (192.243.160.18) is giving back answers. I am not sure why when you try it from your location that even gb.osmre.gov will not respond. You can turn on query logging on BIND, and see if your queries are actually making it all the way to the DNS servers. Hope this helps. On Fri, Jan 16, 2009 at 9:33 AM, Mark A. Moore wrote: > We are having a problem doing an nslookup locally from our BIND DNS Servers > (Master & Secondary) for our own domains. However we can run nslookup on > other domains (ie yahoo, google) with no problems. Even if we stop iptables > we still get the same error. We see no errors when BIND starts. Below is the > command output. Does this have anything to do with /etc/hosts or > /etc/resolv.conf files? We've verified permissions on the directory/files. > > > > nslookup www.osmre.gov > > ;; Got SERVFAIL reply from 192.243.130.42, trying next server > > Server: 192.243.160.18 > > Address:192.243.160.18#53 > > > > ** server can't find www.osmre.gov: SERVFAIL > > > > Thanks for any help provided. > > Mark > > ___ > 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: DNS spoofing
One of the ways you can try is to setup a zone for somedomain.com on your DNS server, assuming your users will query your DNS servers for any outbound recursive lookups. Just create the entries you want in somedomain.com, and your users will get those answers. If your main DNS server is different from the DNS resolver that users point to, you will need to create a forward zone on the resolver to point anything in somedomain.com to your main DNS server (where your own version of the somedomain.com data resides). Hope this helps. On Fri, Jan 16, 2009 at 10:11 AM, Rob Z wrote: > Hello, > we need to deliberately point some of our DNS clients to a host with a > different IP. > Basically, when a client on a certain subnet asks for a host.somedomain.com > they should get an address for host.mydomain.com. > All other DNS information for somedomain.com must be valid for all of my > clients. > I have no control over somedomain.com DNS but I have full controll over our > DNS servers. > What is the best way of doing this with bind? What are other ways of doing > this (eg modify local resolvers)? > Any ideas are greatly appreciated. > -- > Rob > > ___ > 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: DNS spoofing
He states in his messasge that he only wants to change one host in the domain and that all other information for the domain needs to remain intact. If he loads or forwards the domain on his servers nothing other than what he loads will be resolved. -- -Ben Croswell On Fri, Jan 16, 2009 at 1:24 PM, Josh Kuo wrote: > One of the ways you can try is to setup a zone for somedomain.com on > your DNS server, assuming your users will query your DNS servers for > any outbound recursive lookups. Just create the entries you want in > somedomain.com, and your users will get those answers. > > If your main DNS server is different from the DNS resolver that users > point to, you will need to create a forward zone on the resolver to > point anything in somedomain.com to your main DNS server (where your > own version of the somedomain.com data resides). > > Hope this helps. > > On Fri, Jan 16, 2009 at 10:11 AM, Rob Z wrote: > > Hello, > > we need to deliberately point some of our DNS clients to a host with a > > different IP. > > Basically, when a client on a certain subnet asks for a > host.somedomain.com > > they should get an address for host.mydomain.com. > > All other DNS information for somedomain.com must be valid for all of my > > clients. > > I have no control over somedomain.com DNS but I have full controll over > our > > DNS servers. > > What is the best way of doing this with bind? What are other ways of > doing > > this (eg modify local resolvers)? > > Any ideas are greatly appreciated. > > -- > > Rob > > > > ___ > > 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 > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple PTR records
> On Jan 16, 2009, at 7:13 AM, Matus UHLAR - fantomas wrote: > >Actually, it doesn't matter which PTR record will remain, unless there > >will be any SPF record pointing to it. On 16.01.09 10:12, Chris Buxton wrote: > That is a common misconception. No, it is not. > I have seen mail bounced because of a > mismatch between SMTP greeting name and PTR record name. It's not as > common as the simple "is there any PTR record" check, but it does > happen. - it's clear violation of RFC 5321 (and former 2821, 821) - server MUST NOT reject connection because of that. - some (many?,most?) SMTP clients can resolve their local address and use it as HELO string. > The SMTP greeting name should also have an A record that resolves back > to the address used as the source address of the connection. There's "should" contrary to "MUST NOT" RFC section... > I once > saw an SMTP server used to send mail from several unrelated domains, > where each one was sent out through a different address. The mail > server used the same name in the SMTP greeting regardless of which > domain it was sending for, and this caused problems for all of the > other domains. This doesn't say anything about the source of the problem. If someone does not follow RFC's, I don't think we should "fix" the problem on our side. And, again - it does not matter which PTR record will be left. But it must point to hame that points back to the IP. And of course, if you send mail, your MTA should be smart enough (or configured) to know what to use in HELO. -- 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. Posli tento mail 100 svojim znamim - nech vidia aky si idiot Send this email to 100 your friends - let them see what an idiot you are ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS spoofing
Oops, I missed that part. Sorry, yes, as Ben pointed out, my proposed solution will take over *ALL* records in somedomain.com, anything you don't list in your somedomain.com will NOT be resolved. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS spoofing
> Date: Fri, 16 Jan 2009 10:47:27 -0800
> Subject: Re: DNS spoofing
> From: Josh Kuo
> To: Ben Croswell
> Cc: bind-users@lists.isc.org
>
> Oops, I missed that part. Sorry, yes, as Ben pointed out, my proposed
> solution will take over *ALL* records in somedomain.com, anything you
> don't list in your somedomain.com will NOT be resolved.
BUT!... If the NAME of the zone to be spoofed is
zone "HOST.spoofed.zone" IN {
type master;
file "db.HOST.spoofed.zone"
allow-update...
}
And "db.HOST.spoofed.zone" contains: (Of course, you can put anything
in here that you fits your installation...)
@ IN SOA metis.example.net. root.metis.example.net. (
20041217 ; serial number
300; refresh
600; retry
6300 ; expire
300 ) ; minimum TTL
;
; Zone NS records
;
@ IN NS metis.example.net.
;
; Zone records
;
@ IN A 127.0.0.1
Then the ONLY host to be resolved will be $HOST. Anything else falls
through to the original zone.
This solution only takes over ONE (1) host record in the zone.
Regards,
Gregory Hicks
-
Gregory Hicks | Principal Systems Engineer
| Direct: 408.569.7928
People sleep peaceably in their beds at night only because rough men
stand ready to do violence on their behalf -- George Orwell
The price of freedom is eternal vigilance. -- Thomas Jefferson
"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple PTR records
> > I have seen mail bounced because of a > > mismatch between SMTP greeting name and PTR record name. It's not as > > common as the simple "is there any PTR record" check, but it does > > happen. > > - it's clear violation of RFC 5321 (and former 2821, 821) - server MUST NOT > reject connection because of that. In today's spam-filled environment, a "MUST NOT" from RFC 5321 probably rates considerably lower than reducing the total amount of spam. So *if* a postmaster finds out that rejecting mail due to such a mismatch indeed reduces the spam level for his users - he'll probably do it. He may not even have any idea what the RFC says... All I'm saying is - don't expect the RFCs to have the force of law. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple PTR records
I see it all the time on both sides of the fence. I personally support it because even though I sometimes am impacted by it, the amount of actual spam I filter out because of this is significant. >> - it's clear violation of RFC 5321 (and former 2821, 821) - server MUST NOT >> reject connection because of that. >> > > In today's spam-filled environment, a "MUST NOT" from RFC 5321 probably > rates considerably lower than reducing the total amount of spam. So > *if* a postmaster finds out that rejecting mail due to such a mismatch > indeed reduces the spam level for his users - he'll probably do it. He > may not even have any idea what the RFC says... > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SERVFAIL issues
Yes, I read that last night before posting. I changed it to "256M". Is there a way using rndc to see if that "took"? And how do I see how much of the cache has been used? I don't want to provision more than necessary. This server acts as a secondary DNS entry for about 6000 broadband customers and is an authoritative DNS server for 100+ domains. Frank -Original Message- From: Fr34k [mailto:freaknet...@yahoo.com] Sent: Friday, January 16, 2009 8:45 AM To: frnk...@iname.com; bind-users@lists.isc.org Subject: Re: SERVFAIL issues Hello, Has the "max-cache-size" setting in named.conf been considered? If not, note that in early releases of 9.5.x max-cache-size is 32M by default instead of unlimited as in 9.4.x >From the CHANGES file with the bind-9.5.0-P2 source: ""max-cache-size" defaults to 32M" Using: max-cache-size 0 ; will restore previous behavior (unlimited). The ultimate setting would need to be considered for the environment BIND is running in. FWIW, we use max-cache-size 0 ; without issue. You can search this list archives for max-cache-size for previous discussions on this. Thanks. - Original Message From: Frank Bulk To: bind-users@lists.isc.org Sent: Thursday, January 15, 2009 6:57:10 PM Subject: SERVFAIL issues http://marc.info/?l=bind-users&m=122239920822324&w=2 http://marc.info/?l=bind-users&m=122243068905656&w=2 We upgraded to 9.5.0-P1 when the Kaminsky DNS vulnerability was announced and have had intermittent issues with SERVFAIL problems for some DSL modems that don't properly fail over to a secondary DNS server. A packet capture showed that certain domains would result in a SERVFAIL, and once that domain was identified, if we did a dig against it we had the same result. We've had to stop and start the named service about half a dozen times this fall to resolve the issue. We upgraded to 9.5.0-P2 in early November, hoping that this issue would be resolved. But today we experienced the problem again. A customer couldn't query a site, although everything seemed correct. I captured all their traffic and the trace showed that the DNS server was issuing a SERVFAIL. I stopped and then started named and immediately all was well. Since we sometimes reload named when adding/modifying domains, or at other times use rndc, I'm not sure if that "cleared" things up such that this is the first time I recall having this problem in 2 months. Is this intermittent SERVFAIL issue resolved in 9.5.1-P1? Frank ___ 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
version
Hello, How can I get the version of named? -Mike ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: version
> How can I get the version of named? This is cryptic. For "how can I get named to tell me its version", $ named -v Or if you prefer, $ dig +short @localhost txt chaos version.bind For "how can I get the *latest* version of named", http://www.isc.org/download/software/current -- Evan Hunt -- evan_h...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: version
And if you want know the version of a remote name server that you don't own, http://code.google.com/p/fpdns/ On Fri, Jan 16, 2009 at 7:41 PM, Evan Hunt wrote: > > > How can I get the version of named? > > This is cryptic. > > For "how can I get named to tell me its version", > >$ named -v > > Or if you prefer, > >$ dig +short @localhost txt chaos version.bind > > For "how can I get the *latest* version of named", > >http://www.isc.org/download/software/current > > -- > Evan Hunt -- evan_h...@isc.org > Internet Systems Consortium, Inc. > ___ > 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: version
On Fri, 16 Jan 2009, Robert Stucke wrote: And if you want know the version of a remote name server that you don't own, http://code.google.com/p/fpdns/ That is very cool. Thank you. -Mike ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL issues
In article , Frank Bulk - iName.com wrote: >Yes, I read that last night before posting. I changed it to "256M". Is >there a way using rndc to see if that "took"? Note that 9.5.1 reverts the limit to unlimited AND fixes the bug causing the failure. You should not be running 9.5.0 at all. > >And how do I see how much of the cache has been used? I don't want to >provision more than necessary. This server acts as a secondary DNS entry >for about 6000 broadband customers and is an authoritative DNS server for >100+ domains. > >Frank > >-Original Message- >From: Fr34k [mailto:freaknet...@yahoo.com] >Sent: Friday, January 16, 2009 8:45 AM >To: frnk...@iname.com; bind-users@lists.isc.org >Subject: Re: SERVFAIL issues > >Hello, > >Has the "max-cache-size" setting in named.conf been considered? > >If not, note that in early releases of 9.5.x max-cache-size is 32M by >default instead of unlimited as in 9.4.x > >>From the CHANGES file with the bind-9.5.0-P2 source: >""max-cache-size" defaults to 32M" > >Using: >max-cache-size 0 ; >will restore previous behavior (unlimited). > >The ultimate setting would need to be considered for the environment BIND is >running in. > >FWIW, we use max-cache-size 0 ; without issue. > >You can search this list archives for max-cache-size for previous >discussions on this. > >Thanks. > > > >- Original Message >From: Frank Bulk >To: bind-users@lists.isc.org >Sent: Thursday, January 15, 2009 6:57:10 PM >Subject: SERVFAIL issues > >http://marc.info/?l=bind-users&m=122239920822324&w=2 >http://marc.info/?l=bind-users&m=122243068905656&w=2 > >We upgraded to 9.5.0-P1 when the Kaminsky DNS vulnerability was announced >and have had intermittent issues with SERVFAIL problems for some DSL modems >that don't properly fail over to a secondary DNS server. A packet capture >showed that certain domains would result in a SERVFAIL, and once that domain >was identified, if we did a dig against it we had the same result. We've >had to stop and start the named service about half a dozen times this fall >to resolve the issue. > >We upgraded to 9.5.0-P2 in early November, hoping that this issue would be >resolved. But today we experienced the problem again. A customer couldn't >query a site, although everything seemed correct. I captured all their >traffic and the trace showed that the DNS server was issuing a SERVFAIL. I >stopped and then started named and immediately all was well. Since we >sometimes reload named when adding/modifying domains, or at other times use >rndc, I'm not sure if that "cleared" things up such that this is the first >time I recall having this problem in 2 months. > >Is this intermittent SERVFAIL issue resolved in 9.5.1-P1? > >Frank > > >___ >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 -- Tom Schulz sch...@adi.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer Problem - Keep getting not authoritative
In article ,
"Mark A. Moore" wrote:
> We are having some issues with zone transfers b/t our Master & Slave. We
> are using Redhat Linux 5.2 with Bind 9.3.4. In our slave server log, we
> get "not authoritative" for all zones configured. How do we fix the not
> authoritative issue? Any help would be greatly appreciated. Information
> provided has been sanitized a bit. As part of testing, if I created a
> sample fake domain (ie. Youtube.com) and place in the internal-in view
> area as a zone, they transfer with no problems. For anything in the
> external-in view doesn't transfer.
Is the slave internal or external? If the slave is internal, you need
to put the zone in the internal view so the slave can get it.
>
> =20
>
> Sample log message:
>
> received notify for zone 'omitted': not authoritative
>
> =20
>
> =20
>
> Master Named.conf
>
> // Set up ACLs
>
>
> acl "xfer" {
>
>
> omitted;
>
>
> };
>
>
> acl "trusted" {
>
>
> omitted
>
> localhost;
>
>
> };
>
>
> =20
>
> acl "bogon" {
>
>
> omitted
>
> };
>
>
> logging {
>
>
> omitted
>
> };
>
>
> // Set options for security
>
>
> options {
>
>
> directory "/var/named";
>
> pid-file "data/named.pid";
>
>
> statistics-file "data/named.stats";
>
>
> memstatistics-file "data/named.memstats";
>
>
> dump-file "data/named.dump";
>
>
> zone-statistics yes;
>
>
> listen-on { omitted; };
>
>
> transfer-source "10.1.1.1" port 53;
>
> interface-interval 0;
>
>
> # hide our "real" version number
>
>
> version "[secured]";
>
>
> =20
>
> notify yes;
>
>
> transfer-format many-answers;
>
>
> max-transfer-time-in 60;
>
>
> allow-transfer { xfer; };
>
> allow-query { trusted; };
>
>
> blackhole { bogon; };
>
>
> };
>
>
> =20
>
> view "internal-in" in {
>
>
> match-clients { trusted; };
>
>
> recursion yes;
>
>
> additional-from-auth yes;
>
>
> additional-from-cache yes;
>
> zone "." in {
>
>
> type hint;
>
>
> file "db.rootcache";
>
>
> };
>
>
> zone "localhost" in {
>
> type master;
>
> file "db.127.0.0";
>
> };
>
> zone "0.0.127.in-addr.arpa" in {
>
>
> type master;
>
>
> file "localhost.rev";
>
>
> };
>
>
> };
>
>
> // Create a view for external DNS clients.
>
>
> view "external-in" in {
>
>
> match-clients { any; };
>
>
> recursion no;
>
>
> additional-from-auth no;
>
>
> additional-from-cache no;
>
>
> // Link in our zones
>
>
> zone "." in {
>
>
> type hint;
>
>
> file "db.rootcache";
>
>
> };
>
>
> zone "localhost" in {
>
>
> type master;
>
>
> file "db.127.0.0";
>
>
> allow-query { any; };
>
> allow-transfer { 10.1.1.2; };
>
>
> };
>
>
> zone "mydomain.com" in {
>
> type master;
>
>
> file "mydomain.com.hosts";
>
>
> allow-query { any; };
>
> allow-transfer { 10.1.1.2; };
>
> also-notify { 10.1.1.2; };
>
>
> };
>
> zone "1.1.10.in-addr.arpa" in {
>
>
> type master;
>
>
> file "1.1.10.rev";
>
>
> allow-query { any; };
>
> allow-transfer { 10.1.1.2; };
>
> also-notify { 10.1.1.2; };
>
>
> };
>
>
> zone "2.1.10.in-addr.arpa" in {
>
>
> type master;
>
>
> file "2.1.10.rev";
>
>
> allow-query { any; };
>
>
> allow-transfer { 10.1.1.2; };
>
> also-notify { 10.1.1.2; };
>
> };
>
>
> };=20
>
> =20
>
> Slave Named.conf
>
> // Set up ACLs
>
>
> acl "xfer" {
>
>
> none;
>
>
> };
>
>
> acl "trusted" {
>
>
> omitted
>
> localhost;
>
>
> };
>
>
> acl "bogon" {
>
>
> omitted
>
> };
>
>
> logging {
>
>
> omitted
>
>
> };
>
>
> // Set options for security
>
>
> options {
>
>
> directory "/var/named";
>
>
> pid-file "data/named.pid";
>
>
> statistics-file "data/named.stats";
>
>
> memstatistics-file "data/named.memstats";
>
>
> dump-file "data/named.dump";
>
>
> zone-statistics yes;
>
>
> listen-on { 10.1.1.2; };
>
>
> transfer-source 10.1.1.2 port 53;
>
> interface-interval 0;
>
>
> # hide our "real" version number
>
>
> version "[secured]";
>
>
> notify no;
>
>
> transfer-format many-answers;
>
>
> max-transfer-time-in 60;
>
>
> allow-transfer { xfer; };
>
>
> allow-query { trusted; };
>
>
> blackhole { bogon; };
>
>
> };
>
>
> =20
>
> view "internal-in" in {
>
>
> match-clients { trusted; };
>
>
> recursion yes;
>
>
> additional-from-auth yes;
>
>
> additional-from-cache yes;
>
>
> zone "." in {
>
>
> type hint;
>
>
> file "db.rootcache";
>
>
> };
>
>
> zone "localhost" in {
>
> type master;
>
> file "db.127.0.0";
>
> };
>
> zone "0.0.127.in-addr.arpa" in {
>
>
> type master;
>
>
> file "localhost.rev";
>
>
> allow-query { any; };
>
>
> allow-transfer { none; };
>
>
> };
>
>
> };
>
>
> // Create a view for external DNS cli
RE: SERVFAIL issues
Thanks for the info -- is there a way that there can be feature parity, at least in terms of stats reported, between ARM and "rndc stats"? Kind regards, Frank -Original Message- From: JINMEI Tatuya / 神明達哉 [mailto:jinmei_tat...@isc.org] Sent: Friday, January 16, 2009 4:21 PM To: frnk...@iname.com Cc: 'Fr34k'; bind-us...@isc.org Subject: Re: SERVFAIL issues At Fri, 16 Jan 2009 14:24:28 -0600, "Frank Bulk - iName.com" wrote: > Yes, I read that last night before posting. I changed it to "256M". Is > there a way using rndc to see if that "took"? No, but... > And how do I see how much of the cache has been used? ...you can see that info via a HTML-based "statistics channel" (see the ARM for more details). You can also see the configured max-cache-size from that channel. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
