Delegation question
Hi there.. I'm trying to create a delegation to a sub-domain ; for some reasons I'm getting no-where I have a domain.com zone ; I'd like to delegate mel.domain.com to another dns server (windows server DNS fwiw) Here is my zone file: $ORIGIN . $TTL 7200 ; 2 hours domain.com. IN SOA m.domain.com. domainmaster.domain.com. ( 2011020405 ; serial 7200 ; refresh (2 hours) 1800 ; retry (30 minutes) 1209600; expire (2 weeks) 86400 ; minimum (1 day) ) NS m.domain.com. MX 0 mail.domain.com. $ORIGIN domain.com. A 192.168.0.2 ; glue record m A 192.168.0.2 mel A 192.168.0.3 ; NS ad.domain.com ad A 192.168.0.3 --- when NS ad.domain.com line is commented out ; querying for mel.domain.com is properly resolved: bash-3.2# dig @192.168.0.2 mel.domain.com ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.2 mel.domain.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2718 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;mel.domain.com.IN A ;; ANSWER SECTION: mel.domain.com. 7200IN A 192.168.0.3 ;; AUTHORITY SECTION: domain.com. 7200IN NS m.domain.com. ;; ADDITIONAL SECTION: m.domain.com. 7200IN A 192.168.0.2 ;; Query time: 0 msec ;; SERVER: 192.168.0.2#53(192.168.0.2) ;; WHEN: Fri Feb 4 21:45:55 2011 ;; MSG SIZE rcvd: 80 Now if I uncomment the NS ad.domain.com. mel.domain.com will not resolve anymore: bash-3.2# dig @192.168.0.2 mel.domain.com ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.2 mel.domain.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5170 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mel.domain.com.IN A ;; Query time: 30 msec ;; SERVER: 192.168.0.2#53(192.168.0.2) ;; WHEN: Fri Feb 4 21:48:54 2011 ;; MSG SIZE rcvd: 32 For what it's worth; ad.domain.com (the other dns server) properly answer the query: bash-3.2# dig @192.168.0.3 mel.domain.com ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.3 mel.domain.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36709 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mel.domain.com.IN A ;; ANSWER SECTION: mel.domain.com. 600 IN A 192.168.0.3 ;; Query time: 0 msec ;; SERVER: 192.168.0.3#53(192.168.0.3) ;; WHEN: Fri Feb 4 21:49:42 2011 ;; MSG SIZE rcvd: 48 Could someone explained to me what I'm doing wrong ? I've read every documents I could find on this topic ; and they are all doing a similar thing ... Why can't I define NS for my mel.domain.com ? Thank you ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On Fri, Feb 04, 2011 at 09:55:07PM +1100, Jean-Yves Avenard wrote a message of 112 lines which said: > Now if I uncomment the NS ad.domain.com. mel.domain.com will not > resolve anymore: General rule with Unix daemons: always read the log. You'll find the error message. BIND-specific rule: test your zone with named-checkzone. Here, I suggest you will get a "Out of zone data" error (once there is a delegation, the A record for the same name is probably a mistake). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Hi On 4 February 2011 22:15, Stephane Bortzmeyer wrote: > General rule with Unix daemons: always read the log. You'll find the > error message. > > BIND-specific rule: test your zone with named-checkzone. no errors of any kind are reported, in the log nor by named-checkzone > > Here, I suggest you will get a "Out of zone data" error (once there is > a delegation, the A record for the same name is probably a mistake). > hum... named-checkzone domain.com /etc/namedb/sp/db.domain.com zone domain.com/IN: loaded serial 2011020401 OK Actually I just found what caused it not to work ; I have forwarders set ; If I comment-out the forwarders line ; then everything work as it should Can't delegation works if forwarders are enabled ? Thanks Jean-Yves ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
I changed:
zone "domain.com" {
type master;
file "internal/db.domain.com";
check-names ignore;
notify TRUE;
allow-update { key "rndc-key"; };
};
to:
zone "domain.com" {
type master;
file "internal/db.domain.com";
check-names ignore;
notify TRUE;
allow-update { key "rndc-key"; };
// Cancel the forwarding for this authoritative domain.
forwarders {
};
};
and it's working !
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Akadns and Bind
On 4/02/11 3:07 AM, "Tory M Blue" wrote: > On Thu, Feb 3, 2011 at 5:23 PM, Barry Margolin wrote: >> In article > SNIPPED< >> www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com. >> >> And even when they did, it didn't get involved until you followed the >> CNAME returned for www.yahoo.com. Your log message above indicates an >> issue just with the yahoo.com domain, not resolution of the CNAME target. >> >> -- > Thanks Barry so maybe I need some further education > > > [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net > www.yahoo.com > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > What does the log entry say for the above query? Do you reach the problemserver from your client? > So let's add the trace option (Same servers) > > [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com +trace IIRC +trace will ignore @ and look queries up directly to the root on down. So you may have been mislead with the test below. > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net > www.yahoo.com +trace > ; (1 server found) > ;; global options: +cmd > . 514246 IN NS f.root-servers.net. > . 514246 IN NS b.root-servers.net. > . 514246 IN NS e.root-servers.net. > . 514246 IN NS a.root-servers.net. > . 514246 IN NS l.root-servers.net. > . 514246 IN NS k.root-servers.net. > . 514246 IN NS i.root-servers.net. > . 514246 IN NS d.root-servers.net. > . 514246 IN NS c.root-servers.net. > . 514246 IN NS m.root-servers.net. > . 514246 IN NS j.root-servers.net. > . 514246 IN NS h.root-servers.net. > . 514246 IN NS g.root-servers.net. > ;; Received 336 bytes from 10.13.255.101#53(10.13.255.101) in 1 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 494 bytes from 199.7.83.42#53(l.root-servers.net) in 11 ms > > yahoo.com. 172800 IN NS ns1.yahoo.com. > yahoo.com. 172800 IN NS ns5.yahoo.com. > yahoo.com. 172800 IN NS ns2.yahoo.com. > yahoo.com. 172800 IN NS ns3.yahoo.com. > yahoo.com. 172800 IN NS ns4.yahoo.com. > ;; Received 201 bytes from 192.31.80.30#53(d.gtld-servers.net) in 55 ms > > www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf4.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf8.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf3.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf6.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf5.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf7.yahoo.com. > ;; Received 326 bytes from 68.180.131.16#53(ns1.yahoo.com) in 2 ms > > > So what am I missing? No servers available and the trace shows that > it's finding the CNAME record, but doesn't appear to be going far > enough, > > > Here is the second server who can resolve this. Identical > configuration as the problem server, same network segment, behind same > SNAT, the same.. > > [tblue@mx3 ~]$ dig @functioningserver.net www.yahoo.com > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @functioningserver.net > www.yahoo.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30158 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.yahoo.com. IN A > > ;; ANSWER SECTION: > www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com. > fp.wg1.b.yahoo.com. 3238 IN CNAME any-fp.wa1.b.yahoo.com. > any-fp.wa1.b.yahoo.com. 60 IN A 98.137.149.56 > any-fp.wa1.b.yahoo.com. 60 IN A 72.30.2.43 > > ;; AUTHORITY SECTION: > wa1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > wa1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > > ;; Query time: 1759 msec > ;; SERVER: 10.13.255.102#53(10.13.255.102) > ;; WHEN: Thu Feb 3 18:03:55 2011 > ;; MSG SIZE rcvd: 147 That's a small message size so the EDNS entry in your earlier email may be a red herring, but just to be sure why not try the following on the server that fails the lookup? dig +tcp www.yahoo.com @yf2.yahoo.com. I'd also recommend a sanity check on your loadbalancing set up. Are both active in the pool? Have you set up NAT out bound as well as in bound on the VIP? Remembering that UDP can be handled differently through load balancers than TCP. > > I'm missing something I'm sure, but it's under my skin now! > > Thanks again > Tory > ___ > bind-users mailing list > bind-users@lists.isc.o
Re: Delegation question
Just re read that message and it didn't make too much sense so will try again as there is no full stop at the end of the following line ; NS ad.domain.com it would end up looking like this ;domain.com NS ad.domain.com.domain.com if you put a full stop at the end of this line see below it should work NS ad.domain.com. ad A 192.168.0.3 you could also do this NS ad ad A 192.168.0.3 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
> Actually I just found what caused it not to work ; I have forwarders > set ; If I comment-out the forwarders line ; then everything work as > it should > Can't delegation works if forwarders are enabled ? Unless I'm misunderstanding something, it should work. Here's an extract from the BIND 9.7 ARM, section 6.2.16.2: "Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache." How exactly had you configured forwarding in your named.conf file? Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On 4 February 2011 22:51, Balder wrote: > not sure how forwarders fixed this but looking at your zone it is > because you have reset your ORIGIN and not put a fuul stop at the end > of the ad record > ;=as there is no dit at the end of ad.domain.com this will > become. put a full stop at the end of the record and it should work > ;domain.com NS ad.domain.com.domain.com > ; NS ad.domain.com My bad... I improperly copied it; it should have read: NS ad.domain.com. and that's how i had it set up here. If I do not have the forwarders disabled for that particular zone ; it fails ... it's puzzling ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
> mel A 192.168.0.3 > ; NS ad.domain.com You are already defining an A record for "mel". I'd try commenting that one out when you put the NS line back in (and make sure to give that NS line a name of its own then, since it can then no longer piggyback off the previous line you've just commented out). You didn't mention whether you already were commenting out the A record or not. Check your logs to see if BIND complains about anything. Also try pushing your zonefile through named-checkzone. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Hi
On 4 February 2011 22:54, Eivind Olsen wrote:
> Unless I'm misunderstanding something, it should work. Here's an extract
> from the BIND 9.7 ARM, section 6.2.16.2:
>
> "Forwarding occurs only on those queries for which the server is not
> authoritative and does not have the answer in its cache."
>
> How exactly had you configured forwarding in your named.conf file?
I use bind that comes with mac os 10.6 server (9.6.0-APPLE-P2);
named.conf at the beginning includes a file options.conf.apple like so:
options {
include "/etc/dns/options.conf.apple";
};
options.conf.apple contains:
directory "/var/named";
forwarders { 203.59.24.3; 203.0.178.191; 203.134.24.70; };
allow-transfer { none; };
in named.conf I then have:
include "/etc/dns/privateView.conf";
which contains:
view "intranet_view" {
match-clients { 127.0.0.0/8; 192.168.0.0/23; };
allow-recursion { "internal"; };
zone "." {
type hint;
file "named.ca";
};
zone "domain.com" {
type master;
file "internal/db.domain.com";
check-names ignore;
notify TRUE;
allow-update { key "rndc-key"; };
// Cancel the forwarding for this authoritative domain.
forwarders {
};
};
On the other hand ; is the server authoritative for the sub-domain
mel.domain.com provided I added the delegation ?
digg shows something like:
;; AUTHORITY SECTION:
mel.domain.com. 7200IN NS ad.domain.com.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On 4 February 2011 12:28, Jean-Yves Avenard wrote: > I changed: not sure how forwarders fixed this but looking at your zone it is because you have reset your ORIGIN and not put a fuul stop at the end of the ad record domain.com. IN SOA m.domain.com. domainmaster.domain.com. ( 2011020405 ; serial 7200 ; refresh (2 hours) 1800 ; retry (30 minutes) 1209600; expire (2 weeks) 86400 ; minimum (1 day) ) NS m.domain.com. MX 0 mail.domain.com. $ORIGIN domain.com. A 192.168.0.2 ; glue record m A 192.168.0.2 mel A 192.168.0.3 ;=as there is no dit at the end of ad.domain.com this will become. put a full stop at the end of the record and it should work ;domain.com NS ad.domain.com.domain.com ; NS ad.domain.com ad A 192.168.0.3 --- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Dnia 2011-02-04 23:16 Jean-Yves Avenard napisał(a):
>Hi
>
>On 4 February 2011 22:54, Eivind Olsen wrote:
>
>> Unless I'm misunderstanding something, it should work. Here's an extract
>> from the BIND 9.7 ARM, section 6.2.16.2:
>>
>> "Forwarding occurs only on those queries for which the server is not
>> authoritative and does not have the answer in its cache."
>>
>> How exactly had you configured forwarding in your named.conf file?
>
>I use bind that comes with mac os 10.6 server (9.6.0-APPLE-P2);
>
>named.conf at the beginning includes a file options.conf.apple like so:
>options {
>include "/etc/dns/options.conf.apple";
>};
>
>options.conf.apple contains:
>directory "/var/named";
>
>forwarders { 203.59.24.3; 203.0.178.191; 203.134.24.70; };
>
>allow-transfer { none; };
>
>in named.conf I then have:
>include "/etc/dns/privateView.conf";
>
>which contains:
>view "intranet_view" {
>
>match-clients { 127.0.0.0/8; 192.168.0.0/23; };
>
> allow-recursion { "internal"; };
>
>zone "." {
>type hint;
> file "named.ca";
>};
>
>zone "domain.com" {
>type master;
> file "internal/db.domain.com";
> check-names ignore;
>notify TRUE;
> allow-update { key "rndc-key"; };
>// Cancel the forwarding for this authoritative domain.
>forwarders {
>};
>};
>
>On the other hand ; is the server authoritative for the sub-domain
>mel.domain.com provided I added the delegation ?
>digg shows something like:
>;; AUTHORITY SECTION:
>mel.domain.com.7200IN NS ad.domain.com.
This answer is not stating that it's authorative, but only that authorities
are below.
My wild guess ont what's happening, and why disabling forwarders fix this:
without NS m.domain.com is authorative for mel.domain.com, so it answers for
A mel.domain.com without issues.
Now, with NS, it's not authorative, as you've just set up a delegation. So,
when it receives the question it forwards it to one of three forwarding
servers. And they probably don't know how to access ad.domain.com (as it has
private IP adress, and these are public - that's one part of guess), they
end up not resolving the name.
Can verify that 203.59.24.3; 203.0.178.191; 203.134.24.70; can call
192.168.0.3, on that address?
Also, keep in mind that normally you should not use only one NS per
delegation, but a minimum of two. Here, for a testing environment (I guess)
it'll work, but don't do it on production environment.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Akadns and Bind
* Tory M. Blue: > [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com +trace Please use "dig @problemserver.net www.yahoo.com +trace +norecurse +dnssec", to match more closely the queires that BIND would send. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: what's a valid domain name?
To add to the story, I added a rule to our DNS administration system that we'll only allow hostnames that include at least one alphabetic. John On Feb 4, 2011, at 11:26 AM, John Wobus wrote: So 10.14.22.11 is a legal hostname, right? We had a recent experience where our DNS administration system allowed someone to insert in a CNAME record that resembled this: www.example.com. CNAME 10.14.22.11. A fascinating thing about this is that my computer/browser could take me to www.example.com just fine. John Wobus Cornell On Jan 30, 2011, at 7:30 AM, p...@mail.nsbeta.info wrote: From RFC 1123 One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax. p...@mail.nsbeta.info writes: Joseph S D Yao writes: The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. A label must start with a letter? oh I don't think so. How about these domains which all have huge DNS traffic? 163.com 126.com 51.com 56.com yes 163.com is a domain name but "163" also can be treated as a label for domain "com.", is it? Thanks. Regards. ___ 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: what's a valid domain name?
So 10.14.22.11 is a legal hostname, right? We had a recent experience where our DNS administration system allowed someone to insert in a CNAME record that resembled this: www.example.com. CNAME 10.14.22.11. A fascinating thing about this is that my computer/browser could take me to www.example.com just fine. John Wobus Cornell On Jan 30, 2011, at 7:30 AM, p...@mail.nsbeta.info wrote: From RFC 1123 One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax. p...@mail.nsbeta.info writes: Joseph S D Yao writes: The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. A label must start with a letter? oh I don't think so. How about these domains which all have huge DNS traffic? 163.com 126.com 51.com 56.com yes 163.com is a domain name but "163" also can be treated as a label for domain "com.", is it? Thanks. Regards. ___ 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: Delegation question
On Feb 4, 2011, at 3:25 AM, Jean-Yves Avenard wrote: > Actually I just found what caused it not to work ; I have forwarders > set ; If I comment-out the forwarders line ; then everything work as > it should > > Can't delegation works if forwarders are enabled ? Only if either (a) the forwarders can resolve the name, or (b) you disable forwarding for either the authoritative zone or the delegated child zone. What you are seeing is the expected behavior. Keep in mind, a BIND server does two quite different jobs: authoritatively answering queries about local zones and recursive/caching resolution of remote zones. Mixing the two services in one named.conf can be confusing and can lead to complex interplay between their configurations. It can also cause problems for DNSSEC. You should strive to avoid it. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Akadns and Bind
+trace does not do what you think it does. It does not query the target name server for each successive query. Rather, it causes the 'dig' command to perform recursion on its own, only using the indicated server (@server) to seed its root server list. +trace also stops at the CNAME, and does not restart the recursion process as needed to track down the final A record(s). Perform the trace manually, using either +dnssec or at least +bufsize=4096. For example, one step in the process will look like this: dig +bufsize=4096 +norec www.yahoo.com @ns1.yahoo.com You will find that the Yahoo load balancers do not understand EDNS0. This might be part of the problem, although named should be able to work around this automatically. Check the log file (or configure logging as needed and re-run the query against your problem server) to see if it will tell you exactly what the problem is. Chris Buxton BlueCat Networks On Feb 3, 2011, at 6:07 PM, Tory M Blue wrote: > On Thu, Feb 3, 2011 at 5:23 PM, Barry Margolin wrote: >> In article > SNIPPED< >> www.yahoo.com.300 IN CNAME fp.wg1.b.yahoo.com. >> >> And even when they did, it didn't get involved until you followed the >> CNAME returned for www.yahoo.com. Your log message above indicates an >> issue just with the yahoo.com domain, not resolution of the CNAME target. >> >> -- > Thanks Barry so maybe I need some further education > > > [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net > www.yahoo.com > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > So let's add the trace option (Same servers) > > [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com +trace > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net > www.yahoo.com +trace > ; (1 server found) > ;; global options: +cmd > . 514246 IN NS f.root-servers.net. > . 514246 IN NS b.root-servers.net. > . 514246 IN NS e.root-servers.net. > . 514246 IN NS a.root-servers.net. > . 514246 IN NS l.root-servers.net. > . 514246 IN NS k.root-servers.net. > . 514246 IN NS i.root-servers.net. > . 514246 IN NS d.root-servers.net. > . 514246 IN NS c.root-servers.net. > . 514246 IN NS m.root-servers.net. > . 514246 IN NS j.root-servers.net. > . 514246 IN NS h.root-servers.net. > . 514246 IN NS g.root-servers.net. > ;; Received 336 bytes from 10.13.255.101#53(10.13.255.101) in 1 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 494 bytes from 199.7.83.42#53(l.root-servers.net) in 11 ms > > yahoo.com.172800 IN NS ns1.yahoo.com. > yahoo.com.172800 IN NS ns5.yahoo.com. > yahoo.com.172800 IN NS ns2.yahoo.com. > yahoo.com.172800 IN NS ns3.yahoo.com. > yahoo.com.172800 IN NS ns4.yahoo.com. > ;; Received 201 bytes from 192.31.80.30#53(d.gtld-servers.net) in 55 ms > > www.yahoo.com.300 IN CNAME fp.wg1.b.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf4.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf8.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf3.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf6.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf5.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf7.yahoo.com. > ;; Received 326 bytes from 68.180.131.16#53(ns1.yahoo.com) in 2 ms > > > So what am I missing? No servers available and the trace shows that > it's finding the CNAME record, but doesn't a
Re: Akadns and Bind
On Fri, Feb 4, 2011 at 5:37 AM, Florian Weimer wrote: > * Tory M. Blue: > >> [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com +trace > > Please use "dig @problemserver.net www.yahoo.com +trace +norecurse > +dnssec", to match more closely the queires that BIND would send. Okay thanks, done that as well as provided the tcpdump information. The server is being queried it just fails to resolve yahoo but can resolve all others. [tblue@tblue-laptop ~]$ dig @problemserver.net www.yahoo.com ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net www.yahoo.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached [tblue@tblue-laptop ~]$ dig @probelmserver.net.net www.yahoo.com +trace +norecurse +dnssec ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net www.yahoo.com +trace +norecurse +dnssec ; (1 server found) ;; global options: +cmd . 444545 IN NS g.root-servers.net. . 444545 IN NS h.root-servers.net. . 444545 IN NS b.root-servers.net. . 444545 IN NS a.root-servers.net. . 444545 IN NS j.root-servers.net. . 444545 IN NS e.root-servers.net. . 444545 IN NS l.root-servers.net. . 444545 IN NS m.root-servers.net. . 444545 IN NS d.root-servers.net. . 444545 IN NS i.root-servers.net. . 444545 IN NS f.root-servers.net. . 444545 IN NS c.root-servers.net. . 444545 IN NS k.root-servers.net. . 444545 IN RRSIG NS 8 0 518400 2011021000 2011020223 21639 . RdUUiw5gKXpACWIw/O94nxHWSzx5kP62zEhy/kuD8IvY6q1Mbv0GccwL AErMQu3jlWC+3OMsYQmClticjC5eUkuIyvMQikeihkKty6J4IuaoTMYu Xctg2R8QDgIhasF7kNOqdr/Akfk5A2kaeW+jE7OhikMnNUyvi5Ph+ORW XrE= ;; Received 441 bytes from 10.13.255.102#53(10.13.255.102) in 36 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. com.86400 IN NSECcoop. NS RRSIG NSEC com.86400 IN RRSIG NSEC 8 1 86400 2011021100 2011020323 21639 . gR5+PdxFQpmd+bLdUdWH0qmumxkOOwW5PI0Yb0/XwxBGo5NC3UesAUWl PHp5X+6vlhqeJhzZnJRC2XHKFl3LbSnxgvXX3eiGQ8opoSCuF2IqKX3h hGXHqmKvV/bsXJY5FvjfrDMWQYSTS4tt9lURSlBAuJd1jWi+uXtMfafF U0o= ;; Received 718 bytes from 193.0.14.129#53(k.root-servers.net) in 121 ms yahoo.com. 172800 IN NS ns1.yahoo.com. yahoo.com. 172800 IN NS ns5.yahoo.com. yahoo.com. 172800 IN NS ns2.yahoo.com. yahoo.com. 172800 IN NS ns3.yahoo.com. yahoo.com. 172800 IN NS ns4.yahoo.com. ;; Received 212 bytes from 192.43.172.30#53(i.gtld-servers.net) in 38 ms www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com. wg1.b.yahoo.com.300 IN NS yf2.yahoo.com. wg1.b.yahoo.com.300 IN NS yf5.yahoo.com. wg1.b.yahoo.com.300 IN NS yf1.yahoo.com. wg1.b.yahoo.com.300 IN NS yf8.yahoo.com. wg1.b.yahoo.com.300 IN NS yf6.yahoo.com. wg1.b.yahoo.com.300 IN NS yf3.yahoo.com. wg1.b.yahoo.com.300 IN NS yf4.yahoo.com. wg1.b.yahoo.com.300 IN NS yf7.yahoo.com. ;; Received 337 bytes from 68.142.196.63#53(ns4.yahoo.com) in 58 ms I don't see it resolving to an A record, seems to stop after providing a CNAME entry. Also the server in question can easily get to microsoft.com, google.com (I mean resolve), it's just www.yahoo.com and this am it's actually yahoo.com as well. [tblue@tblue-laptop ~]$ dig @ns2.sv.admission.net yahoo.com ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net yahoo.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19162 ;; flags: q
Re: what's a valid domain name?
On Fri, Feb 04, 2011 at 11:26:08AM -0500, John Wobus wrote: > So 10.14.22.11 is a legal hostname, right? > > We had a recent experience where our DNS administration > system allowed someone to insert in a CNAME record that > resembled this: > > www.example.com. CNAME 10.14.22.11. > > A fascinating thing about this is that my computer/browser could > take me to www.example.com just fine. I'm guessing that someone stuck records like: 10.14.22.11 A 10.14.22.11 in your system at Cornell? Otherwise, normally, the CNAME record above would cause errors (i.e., if "10.14.22.11" were not a name, as well). You can't check this with 'nslookup' - you need to use 'dig'. [Nobody need respond with the well-known merits and failings of 'nslookup'.] -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On Fri, Feb 04, 2011 at 09:55:07PM +1100, Jean-Yves Avenard wrote:
> Hi there..
>
> I'm trying to create a delegation to a sub-domain ; for some reasons
> I'm getting no-where
>
> I have a domain.com zone ; I'd like to delegate mel.domain.com to
> another dns server (windows server DNS fwiw)
> Here is my zone file:
...
> domain.com. IN SOA m.domain.com. domainmaster.domain.com. (
...
> )
> NS m.domain.com.
> MX 0 mail.domain.com.
...
> A 192.168.0.2
> ; glue record
> m A 192.168.0.2
> mel A 192.168.0.3
> ; NS ad.domain.com
> ad A 192.168.0.3
> ---
>
> when NS ad.domain.com line is commented out ; querying for
> mel.domain.com is properly resolved:
>
> bash-3.2# dig @192.168.0.2 mel.domain.com
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.2 mel.domain.com
...
> ;; ANSWER SECTION:
> mel.domain.com. 7200IN A 192.168.0.3
...
> Now if I uncomment the NS ad.domain.com. mel.domain.com will not
> resolve anymore:
>
> bash-3.2# dig @192.168.0.2 mel.domain.com
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.2 mel.domain.com
...
> For what it's worth; ad.domain.com (the other dns server) properly
> answer the query:
> bash-3.2# dig @192.168.0.3 mel.domain.com
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.3 mel.domain.com
...
> ;; ANSWER SECTION:
> mel.domain.com. 600 IN A 192.168.0.3
...
As someone else mentioned, the main problem was the lack of a period
('.') at the end of the delegating server name.
I don't remember anyone saying outright that, once you have delegated
the domain, any records intended for that domain in the delegating
domain are completely ignored. [It was hinted at.] In other words,
the "A" record for "mel" above gets ignored when delegation is on. [So
I always put the delegated domain name explicitly in front of a
delegating NS record line.]
Also, you have a pair of completely useless $ORIGIN lines in your file.
I find it very rare that $ORIGIN lines are actually useful in master
copies of zone files. Mostly they confuse, especially if they are
sufficiently far away from where one is focused in the file that one is
not aware how the domain has changed. [In machine-generated files such
as slaved copies of zone files, it's not expected that humans will be
reading the file, so confusion is not a consideration.]
Teaching texts should use comments rather than $ORIGIN lines to indicate
what the domain is at given points in a zone file.
IMHO, of course.
--
/*\
**
** Joe Yao j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Akadns and Bind
In message , Tory M Blue writes: > On Fri, Feb 4, 2011 at 5:37 AM, Florian Weimer wrote: > > * Tory M. Blue: > > > >> [tblue@mx3 ~]$ dig @problemserver.net =A0www.yahoo.com =A0+trace > > > > Please use "dig @problemserver.net www.yahoo.com +trace +norecurse > > +dnssec", to match more closely the queires that BIND would send. > > Okay thanks, done that as well as provided the tcpdump information. > The server is being queried it just fails to resolve yahoo but can > resolve all others. > > [tblue@tblue-laptop ~]$ dig @problemserver.net www.yahoo.com > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net www.yaho= > o.com > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > > [tblue@tblue-laptop ~]$ dig @probelmserver.net.net www.yahoo.com > +trace +norecurse +dnssec > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net > www.yahoo.com +trace +norecurse +dnssec > ; (1 server found) > ;; global options: +cmd > . 444545 IN NS g.root-servers.net. > . 444545 IN NS h.root-servers.net. > . 444545 IN NS b.root-servers.net. > . 444545 IN NS a.root-servers.net. > . 444545 IN NS j.root-servers.net. > . 444545 IN NS e.root-servers.net. > . 444545 IN NS l.root-servers.net. > . 444545 IN NS m.root-servers.net. > . 444545 IN NS d.root-servers.net. > . 444545 IN NS i.root-servers.net. > . 444545 IN NS f.root-servers.net. > . 444545 IN NS c.root-servers.net. > . 444545 IN NS k.root-servers.net. > . 444545 IN RRSIG NS 8 0 518400 2011021000 20 > 11020223 21639 > . RdUUiw5gKXpACWIw/O94nxHWSzx5kP62zEhy/kuD8IvY6q1Mbv0GccwL > AErMQu3jlWC+3OMsYQmClticjC5eUkuIyvMQikeihkKty6J4IuaoTMYu > Xctg2R8QDgIhasF7kNOqdr/Akfk5A2kaeW+jE7OhikMnNUyvi5Ph+ORW XrE=3D > ;; Received 441 bytes from 10.13.255.102#53(10.13.255.102) in 36 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. > com. 86400 IN NSECcoop. NS RRSIG NSEC > com. 86400 IN RRSIG NSEC 8 1 86400 2011021100 2 > 011020323 > 21639 . gR5+PdxFQpmd+bLdUdWH0qmumxkOOwW5PI0Yb0/XwxBGo5NC3UesAUWl > PHp5X+6vlhqeJhzZnJRC2XHKFl3LbSnxgvXX3eiGQ8opoSCuF2IqKX3h > hGXHqmKvV/bsXJY5FvjfrDMWQYSTS4tt9lURSlBAuJd1jWi+uXtMfafF U0o=3D > ;; Received 718 bytes from 193.0.14.129#53(k.root-servers.net) in 121 ms > > yahoo.com.172800 IN NS ns1.yahoo.com. > yahoo.com.172800 IN NS ns5.yahoo.com. > yahoo.com.172800 IN NS ns2.yahoo.com. > yahoo.com.172800 IN NS ns3.yahoo.com. > yahoo.com.172800 IN NS ns4.yahoo.com. > ;; Received 212 bytes from 192.43.172.30#53(i.gtld-servers.net) in 38 ms > > www.yahoo.com.300 IN CNAME fp.wg1.b.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf2.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf5.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf1.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf8.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf6.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf3.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf4.yahoo.com. > wg1.b.yahoo.com. 300 IN NS yf7.yahoo.com. > ;; Received 337 bytes from 68.142.196.63#53(ns4.yahoo.com) in 58 ms > > > I don't see it resolving to an A record, seems to stop after providing > a CNAME entry. > > Also the server in question can easily get to microsoft.com, > google.com (I mean resolve), it's just www.yahoo.com and this am it's > actually yahoo.com as well. > > [tblue@tblue-laptop ~]$ dig @ns2.sv.admission.net yahoo.com > > ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12
Re: Akadns and Bind
> So that was the trace between the client and the nameserver. What > about the trace between the nameserver and the rest of the world? > > The log message is trigger by multiple queries from your nameserver > not being answered and named falling back simpler queries in a > attempt to get them answered. The log message says how much simpler > it made the query before it succeeded. It doesn't tell you the > cause because it doesn't know. > > Mark But Mark Here is where I lose it. the network between the ns server and the world is fine, as proven by the 100's, thousands of looks ups i have done with no issue, other than www.yahoo.com and yahoo.com. The only possible scenario is they are doing some blocking, however that doesn't hold water either since both the functioning and non functioning name server go out to the world as the same IP. So if yahoo was doing any sort of rate limiting or other my other DNS server would exhibit the same issue. It's very obvious that while this working server can resolve any number of domains, yahoo and www.yahoo.com do not. I've shown that my client can access the name server, so the request is being made, but what the name server is doing with it is the question. I will attempt to grab the traffic from this server at the router, a few hops up and see if that helps. But again yahoo only? Just !=network issue in my eyes. But I'll test, just really frustrating and turning on query logging doesn't seem to provide much use, is there something else I can enable in bind to help trace what the server is doing with these queries? Thanks Tory ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Akadns and Bind
In message , Tory M Blue writes: > > So that was the trace between the client and the nameserver. =A0What > > about the trace between the nameserver and the rest of the world? > > > > The log message is trigger by multiple queries from your nameserver > > not being answered and named falling back simpler queries in a > > attempt to get them answered. =A0The log message says how much simpler > > it made the query before it succeeded. =A0It doesn't tell you the > > cause because it doesn't know. > > > > Mark > > But Mark > > Here is where I lose it. the network between the ns server and the > world is fine, as proven by the 100's, thousands of looks ups i have > done with no issue, other than www.yahoo.com and yahoo.com. > > The only possible scenario is they are doing some blocking, however > that doesn't hold water either since both the functioning and non > functioning name server go out to the world as the same IP. So if > yahoo was doing any sort of rate limiting or other my other DNS server > would exhibit the same issue. > > It's very obvious that while this working server can resolve any > number of domains, yahoo and www.yahoo.com do not. I've shown that my > client can access the name server, so the request is being made, but > what the name server is doing with it is the question. I will attempt > to grab the traffic from this server at the router, a few hops up and > see if that helps. But again yahoo only? Just !=3Dnetwork issue in my > eyes. But I'll test, just really frustrating and turning on query > logging doesn't seem to provide much use, is there something else I > can enable in bind to help trace what the server is doing with these > queries? I've seen plenty of wierd errors over the years. Two machines 1 IP address apart. One worked one doesn't. A reboot of a router in the middle of the net was needed to fix that one. Just look at the traffic and trace the fault. > Thanks > Tory > ___ > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Public Advisory on DNSSEC Failures with New DS Records
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colleagues, ISC has issued a public advisory regarding the DNSSEC issue raised on this list earlier this week. All operators who use or plan to use DNSSEC should take careful note, prior to the addition of .com to the signed root at the end of March. The full advisory is located at: https://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record Please do not hesitate to contact us directly with any questions regarding this matter. Larissa Larissa Shapiro ISC Product Manager laris...@isc.org +1 650 423-1335 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNTJWUAAoJEBOIp87tasiUcJUH/0ojZQGLCB2bI31fo7U2OBW3 Ft00kxiMH/bM+EnO+l2aM9SVsPAZBPv9vsP3zvJYOpYPLgxMyap/HwIXmrwu37de gh7cpPAFD48dWK5Txby5F/GMDobbT1UiTTr3BtTGdCHY744siR4w0fNIEbnRLtKB RNUxXRrt/csMs1YQNn05bI4HIooZ8VgNc9pt7c0YcP5+ZWfMJRRnqFGcNxgGxDMt wD5oZ7bej5F035WZhdRpB+rFYvbJ/pKRj3GBYH0yQgI1wRmk92KozPOtGfa0Gjj8 yEJ8Cg1jgGHLtZcjCxqEqaX3XkKWL5D1l0mkt8uq7ut9WWOgIPDpqaF/6aToOnU= =zNed -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC BIND 9.6.3 is now available
__ Introduction BIND 9.6.3 is the current release of BIND 9.6. This document summarizes changes from BIND 9.6.2-P2 to BIND 9.6.3. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest development version of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/development. There you will find additional information about each release, source code, and some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. New Features 9.6.3 None. Feature Changes 9.6.3 None. Security Fixes 9.6.2-P3 * Adding a NO DATA signed negative response to cache failed to clear any matching RRSIG records already in cache. A subsequent lookup of the cached NO DATA entry could crash named (INSIST) when the unexpected RRSIG was also returned with the NO DATA cache entry. [RT #22288] [CVE-2010-3613] [VU#706148] * BIND, acting as a DNSSEC validator, was determining if the NS RRset is insecure based on a value that could mean either that the RRset is actually insecure or that there wasn't a matching key for the RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY RRset. This can happen when in the middle of a DNSKEY algorithm rollover, when two different algorithms were used to sign a zone but only the new set of keys are in the zone DNSKEY RRset. [RT #22309] [CVE-2010-3614] [VU#837744] Bug Fixes 9.6.3 * BIND now builds with threads disabled in versions of NetBSD earlier than 5.0 and with pthreads enabled by default in NetBSD versions 5.0 and higher. Also removes support for unproven-pthreads, mit-pthreads and ptl2. [RT #19203] * HPUX now correctly defaults to using /dev/poll, which should increase performance. [RT #21919] * If named is running as a threaded application, after an "rndc stop" command has been issued, other inbound TCP requests can cause named to hang and never complete shutdown. [RT #22108] * When performing a GSS-TSIG signed dynamic zone update, memory could be leaked. This causes an unclean shutdown and may affect long-running servers. [RT #22573] * A bug in NetBSD and FreeBSD kernels with SO_ACCEPTFILTER enabled allows for a TCP DoS attack. Until there is a kernel fix, ISC is disabling SO_ACCEPTFILTER support in BIND. [RT #22589] * Corrected a defect where a combination of dynamic updates and zone transfers incorrectly locked the in-memory zone database, causing named to freeze. [RT #22614] * Don't run MX checks (check-mx) when the MX record points to ".". [RT #22645] * DST key reference counts can now be incremented via dst_key_attach. [RT #22672] * isc_mutex_init_errcheck() in phtreads/mutex.c failed to destroy attr. [RT #22766] * The Kerberos realm was being truncated when being pulled from the the host prinicipal, make krb5-self updates fail. [RT #22770] * named failed to preserve the case of domain names in RDATA which is not compressible when writing master files. [RT #22863] * There was a bug in how the clients-per-query code worked with some query patterns. This could result, in rare circumstances, in having all the client query slots filled with queries for the same DNS label, essentially ignoring the max-clients-per-query setting. [RT #22972] 9.6.2-P3 * Worked around a race condition in the cache database memory handling. Without this fix a DNS cache DB or ADB could incorrectly stay in an over memory state, effectively refusing further caching, which subsequently made a BIND 9 caching server unworkable. [RT #21818] * Microsoft changed the behavior of sockets between NT/XP based stacks vs Vista/windows7 stacks. Server 2003/2008 have the older behavior, 2008r2 has the new behavior. With the change, different error results are possible, so ISC adapted BIND to handle the new error results. This resolves an issue where sockets would shut down on Windows servers causing named to stop responding to queries. [RT #21906] * Windows has non-POSIX compliant behavior in its rename() and unlink() calls. This caused journal compaction to fail on Windows BIND servers with the log error: "dns_journal_compact failed: failure". [RT #22434] Thank You Thank you to everyone who assisted us in making this release possible. If you w
TC Header Bit Question
RFC 2181, section 9, indicates that name servers should not set the TC bit gratuitously; as long as the answer section is complete, TC should not be set just because the authority and/or additional sections won't also fit in the UDP packet. Using BIND (9.4.3-P3 and 9.7.2-P3) as a resolver doesn't follow this recommendation, however, when querying for the A records of an internal domain consisting of 24 Active Directory domain controllers: ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.7.2-P3 <<>> americas.cpqcorp.net. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49806 ;; flags: qr rd ra; QUERY: 1, ANSWER: 24, AUTHORITY: 13, ADDITIONAL: 6 ... ;; MSG SIZE rcvd: 821 The TC bit is *not* set and only the 24-record answer section is returned in the following circumstances: 1. Configuring the "minimal-responses yes" option (returned message size is 422). 2. Adding a "+bufsize=512" option to the dig command (returned message size is 433). 3. Querying the MS domain controller directly (returned message size is 422). Granted, the RFC states "should" instead of "must" and the set TC bit did reveal a misconfigured firewall that otherwise would have probably gone unnoticed. I'm just curious to know if this is a feature or an oversight. -- Andris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
SO_ACCEPTFILTER in FreeBSD (Was: Re: ISC BIND 9.6.3 is now available)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/04/2011 16:09, Evan Hunt wrote: | * A bug in NetBSD and FreeBSD kernels with SO_ACCEPTFILTER enabled | allows for a TCP DoS attack. Until there is a kernel fix, ISC is | disabling SO_ACCEPTFILTER support in BIND. [RT #22589] This is the first I'm hearing about this problem, and a search of the FreeBSD PR database didn't turn up any hits. If I've missed a memo, my apologies. Could you point me in the right direction? This is clearly something that we'd like to see addressed, and particularly given that we have 2 releases fairly immediately pending, if there is a serious bug in our kernel we'd like to know. Thanks, Doug - -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJNTLsaAAoJEFzGhvEaGryEIvkIAIktb8VCYWRZgpueXFSeTT6Z AE776GJYTPzPHW4aE8vXF7PMyNOE2hlSUVxdzf6jM8EwZtfuf0lErbh3ySih4qzd FLjGqIl2Od3WwBu5K0T+y3A6tHk1+UAmEGJQHXYQArjTCwjMA3rzd5x+lXxyNlKk QEd/86iCeGyOb/WCcdRGEYRrvSw05qI61Snd0RyqIhJjPmJTQ6/KbXGl1jyo4d0q GIIbwnci0uNCYdmY0m30J+tZmmmus0Novf4iBMHJpyLdSvTw4EnUGPLJIDDcOsSE HcqFCXexV2EwuV4Ss/lkPZJHEwzIKtyU1o5PGS/4YB0hl7JOi4jB4gCYaIofH/U= =ie9b -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
In article ,
Jean-Yves Avenard wrote:
> Actually I just found what caused it not to work ; I have forwarders
> set ; If I comment-out the forwarders line ; then everything work as
> it should
>
> Can't delegation works if forwarders are enabled ?
No. When you have forwarders configured, it means "When you need to
recurse to answer a query, forward the query to the forwarders instead
of following delegation records."
Why did you configure forwarders in the first place if your server can
follow delegations? Do you think there's a difference between
delegations from your own zone (you want to follow) and delegations from
the root (you want to use the forwarders)?
You can override the general forwarders option by configuring a
forwarding zone:
zone "mel.domain.com" {
type forward;
forwarders {};
};
The empty forwarders clause in here disables forwarders, so it follows
delegations.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Akadns and Bind
On Feb 4, 2011, at 1:11 PM, Chris Buxton wrote: > +trace does not do what you think it does. It does not query the target name > server for each successive query. Rather, it causes the 'dig' command to > perform recursion on its own, only using the indicated server (@server) to > seed its root server list. Ok, so this is at least the 6th time (that I can remember) that the behavior of +trace and @server has caused confusion on the list --- perhaps it is worth opening a feature request to make dig present an informational message if these 2 options are chosen? W > +trace also stops at the CNAME, and does not restart the recursion process as > needed to track down the final A record(s). > > Perform the trace manually, using either +dnssec or at least +bufsize=4096. > For example, one step in the process will look like this: > > dig +bufsize=4096 +norec www.yahoo.com @ns1.yahoo.com > > You will find that the Yahoo load balancers do not understand EDNS0. This > might be part of the problem, although named should be able to work around > this automatically. Check the log file (or configure logging as needed and > re-run the query against your problem server) to see if it will tell you > exactly what the problem is. > > Chris Buxton > BlueCat Networks > > On Feb 3, 2011, at 6:07 PM, Tory M Blue wrote: > >> On Thu, Feb 3, 2011 at 5:23 PM, Barry Margolin wrote: >>> In article >> SNIPPED< >>> www.yahoo.com.300 IN CNAME fp.wg1.b.yahoo.com. >>> >>> And even when they did, it didn't get involved until you followed the >>> CNAME returned for www.yahoo.com. Your log message above indicates an >>> issue just with the yahoo.com domain, not resolution of the CNAME target. >>> >>> -- >> Thanks Barry so maybe I need some further education >> >> >> [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com >> >> ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net >> www.yahoo.com >> ; (1 server found) >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached >> >> So let's add the trace option (Same servers) >> >> [tblue@mx3 ~]$ dig @problemserver.net www.yahoo.com +trace >> >> ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @problemserver.net >> www.yahoo.com +trace >> ; (1 server found) >> ;; global options: +cmd >> .514246 IN NS f.root-servers.net. >> .514246 IN NS b.root-servers.net. >> .514246 IN NS e.root-servers.net. >> .514246 IN NS a.root-servers.net. >> .514246 IN NS l.root-servers.net. >> .514246 IN NS k.root-servers.net. >> .514246 IN NS i.root-servers.net. >> .514246 IN NS d.root-servers.net. >> .514246 IN NS c.root-servers.net. >> .514246 IN NS m.root-servers.net. >> .514246 IN NS j.root-servers.net. >> .514246 IN NS h.root-servers.net. >> .514246 IN NS g.root-servers.net. >> ;; Received 336 bytes from 10.13.255.101#53(10.13.255.101) in 1 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 494 bytes from 199.7.83.42#53(l.root-servers.net) in 11 ms >> >> yahoo.com. 172800 IN NS ns1.yahoo.com. >> yahoo.com. 172800 IN NS ns5.yahoo.com. >> yahoo.com. 172800 IN NS ns2.yahoo.com. >> yahoo.com. 172800 IN NS ns3.yahoo.com. >> yahoo.com. 172800 IN NS ns4.yahoo.com. >> ;; Received 201 bytes from 192.31.80.30#53(d.gtld-servers.net) in 55 ms >> >> www.yahoo.com. 300 IN CNAME fp.wg1.b.yahoo.com. >> wg1.b.yahoo.com. 300 IN NS yf2.yahoo.com. >> wg1.b.yahoo.com. 300 IN NS yf4.yahoo.com. >> wg1.b.yahoo.com. 300 IN NS yf8.yahoo.com. >> wg1.b.yahoo.com. 300 IN NS yf3.yahoo.com. >> wg1.b.yahoo.com. 300 IN NS
