Problem resolving one particular domain
Hi, I'm running three DNS servers (1 master, 2 slaves) running bind 9.7.3, hosting about 150 domains, while also providing DNS service for my network. Recently a customer complained that they cannot send an email (they use my SMTP server) to a specific domain 'rabobank.com' - Postfix logged this error: 'Host or domain name not found.' Initially I thought there was a problem with the domain, so I checked with 'dig' only to find that it really cannot resolve anything regarding this domain. Then I checked domain registration using 'whois' and it seemed OK. So I used 'dig' to query my ISP's DNS server, which resolved the domain in question without a problem. For a quick fix I just configured my named to use forwarders. But I would like to get to the bottom of this, so I did some more testing without forwarders. The domain is using three name servers: # dig +short ns rabobank.com @ns1.telemach.net ns2.rabobank.nl. ns.rabobank.nl. ns.nl.net. Incidentally there is also the domain 'rabobank.nl' that uses those same servers: # dig +short ns rabobank.nl @ns1.telemach.net ns2.rabobank.nl. ns.nl.net. ns.rabobank.nl Weirdness number 1 - I cannot resolve 'rabobank.com', yet I can resolve 'rabobank.nl': # dig ns rabobank.com ; DiG 9.7.3-P1 ns rabobank.com ;; global options: +cmd ;; connection timed out; no servers could be reached # dig ns rabobank.nl ; DiG 9.7.3-P1 ns rabobank.nl ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4961 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;rabobank.nl. IN NS ;; ANSWER SECTION: rabobank.nl.3188IN NS ns.rabobank.nl. rabobank.nl.3188IN NS ns.nl.net. rabobank.nl.3188IN NS ns2.rabobank.nl. ;; ADDITIONAL SECTION: ns.nl.net. 85663 IN A 193.78.240.1 ns.rabobank.nl. 3032IN A 145.72.79.222 ns2.rabobank.nl.2879IN A 145.72.79.221 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jul 27 09:38:11 2011 ;; MSG SIZE rcvd: 135 Weirdness number 2 - using dig directly with their servers works: # dig ns rabobank.com @145.72.79.221 ; DiG 9.7.3-P1 ns rabobank.com @145.72.79.221 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47023 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;rabobank.com. IN NS ;; ANSWER SECTION: rabobank.com. 3600IN NS ns2.rabobank.nl. rabobank.com. 3600IN NS ns.nl.net. rabobank.com. 3600IN NS ns.rabobank.nl. ;; Query time: 39 msec ;; SERVER: 145.72.79.221#53(145.72.79.221) ;; WHEN: Wed Jul 27 09:39:46 2011 ;; MSG SIZE rcvd: 99 I tried the same with all three servers. So I guess it's not a network problem... I thought 'dig +trace' would give some answers, but it seems it doesn't even use my named to resolve the domain - instead it seems to talk directly to root server and the target server: # dig +trace ns rabobank.com ; DiG 9.7.3-P1 +trace ns rabobank.com ;; global options: +cmd . 517503 IN NS m.root-servers.net. . 517503 IN NS d.root-servers.net. . 517503 IN NS g.root-servers.net. . 517503 IN NS k.root-servers.net. . 517503 IN NS j.root-servers.net. . 517503 IN NS b.root-servers.net. . 517503 IN NS h.root-servers.net. . 517503 IN NS e.root-servers.net. . 517503 IN NS l.root-servers.net. . 517503 IN NS i.root-servers.net. . 517503 IN NS a.root-servers.net. . 517503 IN NS c.root-servers.net. . 517503 IN NS f.root-servers.net. ;; Received 276 bytes from 127.0.0.1#53(127.0.0.1) 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
Re: Forward only zones.
On 26.07.2011 00:48, Kevin Darcy wrote: Correct. That's the distinction which is typically made between a DNS *forwarder* (which caches) and a DNS *proxy* (which doesn't). As far as I know, BIND cannot be configured to be a DNS proxy. On 26.07.11 11:11, Vbvbrj wrote: But I don't want BIND as a proxy. ) If you want BIND not to cache, you want a proxy. However BIND can't do this now. Answers from its cache, that may be out of date. This is tunable via the TTL values on the relevant RRsets. Consult the manual of your authoritative DNS server software, for details. TTL or expires must be lowered at microsoft DNS? yes. TTL for records, expires only if oyou fetch zones. Note that microsoft's DNS servers are very bad at maintaining zones (especially those dynamically updated by clients) -- 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. 99 percent of lawyers give the rest a bad name. ___ 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: Problem resolving one particular domain
On 07/27/2011 10:31 AM, Stephane Bortzmeyer wrote: On Wed, Jul 27, 2011 at 09:59:32AM +0200, Danilo Godecdanilo.go...@agenda.si wrote a message of 247 lines which said: Weirdness number 2 - using dig directly with their servers works: Nothing weird here: dig does not behave like the BIND resolver. It does not use EDNS at all by default, it does not use the same source port, etc. Yes, I was expecting that - I just used it as a way of checking whether it's a network/firewall problem (being blocked or something). 09:53:23.643138 178.79.70.66.53 145.72.79.222.53: [udp sum ok] 7984 [1au] A? ns.rabobank.nl. ar: . OPT UDPsize=512 (43) (ttl 63, id 5640, len 71) There is one weird thing here: your resolver uses always the same source port, 53: 1) It means you are vulnerable to Kaminsky-style cache poisoning. In 2011, 'query-source port 53;' should have disappeared a long time ago. Source ports must be random. 2) It may create problems with some firewalls (this would not explain why rabobank.nl, on the same servers, work). Thank you, that's what it was. Removed the 'query-source port 53' and resolving started working. It is still very weird why it worked with 'rabobank.nl'... A second weird thing is the use of EDNS with a buffer size of 512. This is completely useless, since default size is already 512 (but it is probably not the cause of the problem since all answers from Rabobank are short). In the process of trying to figure out the problemI was fiddling with the 'edns-udp-size' option setting it to 512. I guess I still had that in when I was doing the copypaste - have since removed it and the packets sent out now have 'OPT UDPsize=4096'. Thanks again, Danilo ___ 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: Problem resolving one particular domain
On Wed, Jul 27, 2011 at 10:31:30AM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 34 lines which said: 1) It means you are vulnerable to Kaminsky-style cache poisoning. In 2011, 'query-source port 53;' should have disappeared a long time ago. For the record, there are still around 1 % of queries (1.5 % of resolvers) coming towards .FR authoritative name servers which have source port 53 :-( ___ 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: Problem resolving one particular domain
In message 4e2fea67.7080...@agenda.si, Danilo Godec writes: On 07/27/2011 10:31 AM, Stephane Bortzmeyer wrote: On Wed, Jul 27, 2011 at 09:59:32AM +0200, Danilo Godecdanilo.go...@agenda.si wrote a message of 247 lines which said: Weirdness number 2 - using dig directly with their servers works: Nothing weird here: dig does not behave like the BIND resolver. It does not use EDNS at all by default, it does not use the same source port, etc. Yes, I was expecting that - I just used it as a way of checking whether it's a network/firewall problem (being blocked or something). Well it is a firewall problem. Yet another administator that thinks queries only come from ports above 1023 despite DNS queries being sourced from port 53 for decades. You can test by binding the source port. dig ns.rabobank.nl @145.72.79.222 -b 0.0.0.0#1023 dig ns.rabobank.nl @145.72.79.222 -b 0.0.0.0#1024 If your are writing firewall rules you need to realise that source ports mean absolutely nothing. The only invalid source port is zero. 09:53:23.643138 178.79.70.66.53 145.72.79.222.53: [udp sum ok] 7984 [1au] A? ns.rabobank.nl. ar: . OPT UDPsize=512 (43) (ttl 63, id 5640, len 71) There is one weird thing here: your resolver uses always the same source port, 53: 1) It means you are vulnerable to Kaminsky-style cache poisoning. In 2011, 'query-source port 53;' should have disappeared a long time ago. Source ports must be random. 2) It may create problems with some firewalls (this would not explain why rabobank.nl, on the same servers, work). Thank you, that's what it was. Removed the 'query-source port 53' and resolving started working. It is still very weird why it worked with 'rabobank.nl'... A second weird thing is the use of EDNS with a buffer size of 512. This is completely useless, since default size is already 512 (but it is probably not the cause of the problem since all answers from Rabobank are short). In the process of trying to figure out the problemI was fiddling with the 'edns-udp-size' option setting it to 512. I guess I still had that in when I was doing the copypaste - have since removed it and the packets sent out now have 'OPT UDPsize=4096'. Thanks again, Danilo ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: stub zone
On Jul 26, 2011, at 10:51 PM, Feng He wrote:
On Wed, Jul 27, 2011 at 8:51 AM, Chris Buxton chris.p.bux...@gmail.com
wrote:
On Jul 25, 2011, at 10:33 PM, Feng He wrote:
On Tue, Jul 26, 2011 at 3:55 AM, ju wusuo juwu...@yahoo.com wrote:
Would like to use the BIND stub zone function, however, heard that ISC
considers stopping support to stub zone in the future, is that true?
___
Hi,
what's the use of stub zone? I never used it, thanks.
A stub zone is conceptually similar to the root hints zone, but for a domain
other than the root. It's a way to add NS and glue records to the cache as a
way to either optimize recursion performance or overlay a private namespace
onto the public Internet.
For example, suppose you have a name server with this configuration:
options {
some stuff goes here
};
zone bluecatnetworks.com {
type stub;
masters { 192.168.0.1; };
};
Thanks.
So, what's the difference between a stub zone and a slave zone?
I think the configure:
zone bluecatnetworks.com {
type slave;
masters { 192.168.0.1; };
};
Will be able to have the same effect.
Mostly, yes. The difference is that with the slave zone, the server is
authoritative. This may have undesirable side effects:
- You must consider either using a low refresh timer or configuring DNS notify
on the master.
- It may cause problems for DNSSEC-aware clients that hit the server.
- It takes more memory and possibly more bandwidth. For a single zone, probably
not a problem, but suppose there are 1 or more zones involved.
Chris Buxton
BlueCat Networks
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS update on host down
On 07/26/11 07:23, Paul Reilly wrote: Is there a simple utility, which can ICMP ping or HTTP ping a host, and update the hosts DNS entry if the host is down? Will a significant number of your users have locally cached the out-of-date entry? -- Gloria Rom UCLA Library Information Technology glor...@library.ucla.edu ___ 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: Views and no answers ...
These two views are identical in any way I can see, so the fault may be
in an included configuration file that is not included in your message.
Look for allow-query, allow-recursion or allow-cache statements in your
other config files.
When using views, I often find it more manageable to move such options
inside the view definition.
Mvh. / Regards
Bob
On 2011-07-25 16:24, Thomas Schweikle wrote:
Hi!
I have set up a view for one site. It is bound to change answers as
necessary for different IP-ranges. It works as far as I could see.
But with one ip-range there is a problem ...
I can query internal addresses:
!user@kvm2~# host intweb.example.de
!web.example.de has address 192.168.180.46
But external ones do not work:
!user@kvm2:~# host google.com
!user@kvm2:~#
The host I am trying on has address 192.168.112.4 and I've set up my
view as:
!view ex {
!match-clients { 192.168.112.0/23; };
!recursion yes;
!
!include /etc/named/master/rootns.conf;
!include /etc/named/master/localhost.conf;
!include /etc/named/master/empty.conf;
!
!zone example.de. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zhz/fwd.example;
!};
!zone 112.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.1;
!};
!};
!view in {
!match-clients { 192.168.180.0/23; };
!recursion yes;
!
!include /etc/named/master/rootns.conf;
!include /etc/named/master/localhost.conf;
!include /etc/named/master/empty.conf;
!
!zone example.de. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zhz/fwd.example;
!};
!zone 112.168.192.in-addr.arpa. {
!type master;
!allow-transfer { key mskey; };
!notify no;
!file /etc/named/zin/rev.192.168.1;
!};
!};
Any idea why the server resolves internal names, but no external
ones to view ex, while it does answer internal and external names
to view in?
I've set up query logging, but this just tells me queries are
correctly processed. But not why no answer was sent.
In the server logs I can watch queries from 192.168.180.0/23 tagged
with in and such from 192.168.112.0/23 with ex. Addresses
defined by my server are served to both clients in and ex.
Addresses from others like google.com are only served to clients
from in not to clients from ex (server answers NXDOMAIN).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS update on host down
In message 4e307a5c.9070...@library.ucla.edu, Gloria Rom writes: On 07/26/11 07:23, Paul Reilly wrote: Is there a simple utility, which can ICMP ping or HTTP ping a host, and update the hosts DNS entry if the host is down? Ping + nsupdate can do this. Note if you applications are properly written they can cope with a host being down. http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-03 is all about fixing applications to do just that. Google Crome and Firefix already implement versions of this. Will a significant number of your users have locally cached the out-of-date entry? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
