Re: Slaves and views
On Mar 4, 2011, at 11:34 PM, Joseph S D Yao wrote: > On Fri, Mar 04, 2011 at 06:55:07PM -0800, Chris Buxton wrote: > ... >> >> With a static-stub zone (new in BIND 9.8), your server would not prime its >> cache with the bad NS rrset from the authoritative server. It would simply >> start all query resolution for the domain in question (possibly bigger than >> the zone) at that server, thus bypassing the bad NS rrset. >> > ... > > > With this description, I have to ask, how does it then differ from a > forward-only domain? A static-stub zone involves an iterative query, the potential for a referral, and then potentially recursion to follow the referral. Conditional forwarding (a zone of type forward) involves a recursive query. If the answer is not forthcoming and 'forward only;' is set, the result is a SERVFAIL back to the client. There is no possibility that the DNS server so configured will follow referrals. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind 9.8.0 BUG dlz zone transfer
Tested bind 9.4, 9.6, 9.7 and 9.8, 9.8 is only version giving this problem. The issue is when initiating a, bind only slave, to slave off of a, dlz/mysql+bind master, debug logs show: "refresh: non-authoritative answer from master" I had set debugging on slave and master all night long on all versions of bind, and queries seem fine on 9.8, I can tell for certain queries are executing perfect like the previous versions and returning responses as they should, so I have ruled out mysql, there must be a bug within the 9.8 source tree doing this not updating aa SOA bit. Dan. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
2011/3/5 Mark Andrews : >> So why does ns33.domaincontrol.com answer with ANSWER SECTION rather >> than AUTHORITY SECTION? > > If you ask with rd=0 (+norec), which is what nameservers do, you > get the referral. Presumably ns33.domaincontrol.com is running > BIND 8 which didn't fully comply the RFC 1034. One of the reasons > for writing BIND 9 was to sort out these corner cases. > > If rd=1 BIND 8 assumed that there was a stub resolver talking to > it so it put the response in the answer section despite it not being > authoritative for the child zone. It rd=0 it did what RFC 1034 > said to do, put the response in the authority section. > > BIND 9 will actually recurse if rd=1 and the client is in the > allow-recursion acl and fetch the answer from the child zone and > return it. If not it will return a referral. > That's the great answer. You have cleaned my confusion which exists long time in my head. Thanks a lot Mark. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
In message , terr y writes: > > > > But in this case, you're asking the authotrative server. Authorative server > > answers in answer section, as it knows the answer. Authorative section is > > for 'I don't know, ask ...' > > The rule above goes for servers which are not authorative for a given zone. > > Torinthiel > > ___ > > > I'm very sorry, just by typo, I do mean this case: > > $ dig test.nsbeta.info ns @ns33.domaincontrol.com > > ; <<>> DiG 9.4.2-P2.1 <<>> test.nsbeta.info ns @ns33.domaincontrol.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13538 > ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;test.nsbeta.info. IN NS > > ;; ANSWER SECTION: > test.nsbeta.info. 3600IN NS ns2.dnsbed.com. > test.nsbeta.info. 3600IN NS ns1.dnsbed.com. > > ;; Query time: 186 msec > ;; SERVER: 216.69.185.17#53(216.69.185.17) > ;; WHEN: Sat Mar 5 09:36:58 2011 > ;; MSG SIZE rcvd: 122 > > > So why does ns33.domaincontrol.com answer with ANSWER SECTION rather > than AUTHORITY SECTION? If you ask with rd=0 (+norec), which is what nameservers do, you get the referral. Presumably ns33.domaincontrol.com is running BIND 8 which didn't fully comply the RFC 1034. One of the reasons for writing BIND 9 was to sort out these corner cases. If rd=1 BIND 8 assumed that there was a stub resolver talking to it so it put the response in the answer section despite it not being authoritative for the child zone. It rd=0 it did what RFC 1034 said to do, put the response in the authority section. BIND 9 will actually recurse if rd=1 and the client is in the allow-recursion acl and fetch the answer from the child zone and return it. If not it will return a referral. Mark ; <<>> DiG 9.6.0-APPLE-P2 <<>> test.nsbeta.info +norec @ns33.domaincontrol.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16305 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.nsbeta.info. IN A ;; AUTHORITY SECTION: test.nsbeta.info. 3600IN NS ns2.dnsbed.com. test.nsbeta.info. 3600IN NS ns1.dnsbed.com. ;; Query time: 400 msec ;; SERVER: 216.69.185.17#53(216.69.185.17) ;; WHEN: Sat Mar 5 14:20:26 2011 ;; MSG SIZE rcvd: 122 -- 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
Re: CVE-2011-0414 and Bind 9.7.3
> How sure are we that 9.7.3 fixes CVE-2011-0414? Pretty darn sure. > Because we are seeing behaviour that looks like CVE-2011-0414 > on our 9.7.3 server... Please send details to bind9-b...@isc.org. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Mar 4, 2011, at 5:42 PM, terry wrote: > 2011/3/5 Chris Buxton : >> >> On Mar 4, 2011, at 8:46 AM, John Wobus wrote: >> >>> Hi, >>> >>> Can a zone file a slave in one view and the same zone file >>> be served by another view? >> >> You can do this for static master zones, but it's not a good idea for slaves. >> >> Depending on the use case for your internal view, you may be able to solve >> this better using forwarding, stub zones, or (BIND 9.8 only) static-stub >> zones. > > > Chris, > > What's the difference between a stub zone and a static-stub zone? > I have been thinking they are the same. With a stub zone, your server would ask the server with bad NS records for the NS record set, and would then try to resolve all queries against the zone using that NS rrset. With a static-stub zone (new in BIND 9.8), your server would not prime its cache with the bad NS rrset from the authoritative server. It would simply start all query resolution for the domain in question (possibly bigger than the zone) at that server, thus bypassing the bad NS rrset. Regards, Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
CVE-2011-0414 and Bind 9.7.3
How sure are we that 9.7.3 fixes CVE-2011-0414? Because we are seeing behaviour that looks like CVE-2011-0414 on our 9.7.3 server... Thanks, John --- John Hascall, j...@iastate.edu Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services) IT Services, The Iowa State University of Science and Technology ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
2011/3/5 Chris Buxton : > > On Mar 4, 2011, at 8:46 AM, John Wobus wrote: > >> Hi, >> >> Can a zone file a slave in one view and the same zone file >> be served by another view? > > You can do this for static master zones, but it's not a good idea for slaves. > > Depending on the use case for your internal view, you may be able to solve > this better using forwarding, stub zones, or (BIND 9.8 only) static-stub > zones. Chris, What's the difference between a stub zone and a static-stub zone? I have been thinking they are the same. Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
> > But in this case, you're asking the authotrative server. Authorative server > answers in answer section, as it knows the answer. Authorative section is > for 'I don't know, ask ...' > The rule above goes for servers which are not authorative for a given zone. > Torinthiel > ___ I'm very sorry, just by typo, I do mean this case: $ dig test.nsbeta.info ns @ns33.domaincontrol.com ; <<>> DiG 9.4.2-P2.1 <<>> test.nsbeta.info ns @ns33.domaincontrol.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13538 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;test.nsbeta.info. IN NS ;; ANSWER SECTION: test.nsbeta.info. 3600IN NS ns2.dnsbed.com. test.nsbeta.info. 3600IN NS ns1.dnsbed.com. ;; Query time: 186 msec ;; SERVER: 216.69.185.17#53(216.69.185.17) ;; WHEN: Sat Mar 5 09:36:58 2011 ;; MSG SIZE rcvd: 122 So why does ns33.domaincontrol.com answer with ANSWER SECTION rather than AUTHORITY SECTION? Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Sat, Mar 05, 2011 at 09:36:56AM +1100, Mark Andrews wrote:
...
> masters { 127.0.0.1 key external.key; };
...
Hmmm! You can do that, can't you? I tend to try to keep one key to one
IP address in a view - people get confused even so.
As I said, this still does two zone transfers, because sourcing the zone
and serving it are not separate abstractions.
--
/*\
**
** 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: Slaves and views
On Fri, Mar 04, 2011 at 11:46:05AM -0500, John Wobus wrote:
...
> Can a zone file a slave in one view and the same zone file
> be served by another view?
...
I assume you mean something like this:
view "here" {
match-clients { "here"; };
zone "example.us" {
type slave;
file "data/zone.example.us";
masters { 20.20.20.20; 30.30.30.30; };
};
};
view "rest" {
match-clients { any; };
zone "example.us" {
type master;
file "data/zone.example.us";
}
};
I've tried this - unsuccessfully. The basic problem is, if you declare
both "slaves", then the second view tries to update it around the same
time as the first, and the file gets munged. If you declare one
"slave" and the other "master", how does the "slave" view let the
"master" view know when the zone is updated? Nothing like serving stale
data!
view "here" {
match-clients { "here"; };
zone "example.us" {
type slave;
file "data/here/zone.example.us";
masters { 20.20.20.20; 30.30.30.30; };
};
};
view "rest" {
match-clients { any; };
zone "example.us" {
type slave;
file "data/rest/zone.example.us";
masters { 20.20.20.20; 30.30.30.30; };
}
};
The above does two zone transfers, which is a waste [but not a big one,
one hopes!]. But I couldn't figure out any syntax - without using the
extra IP addresses that you also wish to avoid - for doing this. Using
extra IP addresses, of course, each view listens on a different IP
address, the second view slaves its copy from the slaved copy on the
first, and the first view NOTIFYes the second when it transfers the
master copy "out there" to its slaved copy. Still two zone transfers,
but one is internal.
To do what you want, one would have to separately abstract the zone
transfer mechanism and the serving mechanism. Which would not be a bad
idea at all:
// NOTE: the following is ramblings of my feverish mind and not anything
// supported by any existing parser or other software
view "here" { match-clients { "here"; }; allow-query { "here"; }; };
view "rest" { match-clients { any; }; };
zone "static.us" {
// sourced once
// served by all views
type master;
file "data/zone.static.us";
}
zone "example.us"
// sourced once
// served by all views
type slave;
file "slaved/zone.example.us";
masters { 20.20.20.20; 30.30.30.30; };
// if it were served differently in another view
// or sourced differently in a third view
// we would have that info in a 'view' statement.
}
zone "split.us" {
// sourced and served differently in two views
view "here" {
match-clients { !ext-tsig-key; int-tsig-key; "here"; };
allow-transfer { int-tsig-key; };
type slave;
file "slaved/here/zone.example.us";
masters { 10.10.10.10; 10.20.30.40; };
}
view "rest" {
match-clients { !int-tsig-key; ext-tsig-key; any; };
allow-transfer { ext-tsig-key; };
type slave;
file "slaved/rest/zone.example.us";
masters { 20.20.20.20; 30.30.30.30; };
}
}
zone "internal.us" {
// sourced and served only in one view
view "here" {
type master;
file "data/internal.us";
}
}
--
/*\
**
** 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: Slaves and views
In message <79391b3d-6106-420b-9056-717a5e5fa...@cornell.edu>, John Wobus write
s:
> Hi,
>
> Can a zone file a slave in one view and the same zone file
> be served by another view?
>
> I'm going to split our authoritative servers into internal
> and external views. My question concerns zones that we
> secondary for other organizations, slaved to masters at
> their sites.
>
> I know I could configure each of their zones with separate files
> in each the two views, listen/use an additional address that
> accesses our local view, and tell these peer organizations to
> notify and allow transfers from this additional address.
> I'm not (yet) worried about dynamic updates, if there are
> any.
>
> Is there a way I can handle their zones without making
> these other sites configure another address, and I still
> run just one bind instance?
>
> Other ideas are: running a separate bind instance for
> these zones, or making one view a slave to the other.
> Possibly forwarding of some kind, another thing I haven't
> done much.
>
> John Wobus
> Cornell
Any file named writes, slave, dynamic master, should not be shared.
That said you don't need to change how zone are transfered between
you and the master. You can just transfer them internally from
one view to the other.
key "external.key" {
};
acl internal-clients {
...
127.0.0.1;
};
view "internal" {
match-clients {
!key external.key;
internal-clients;
};
zone "example" {
type slave;
file "slave/internal/example";
masters { 127.0.0.1 key external.key; };
};
};
view "external" {
match-clients {
key external.key;
any;
};
zone "example" {
type slave;
file "slave/external/example";
masters { };
allow-transfer { external.key; };
also-notify { 127.0.0.1; };
};
};
> ___
> 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
Re: BIND servfail from caching server
Thanks, I was able to setup a forward zone in the caching servers for
supernet.com and forward to the ns{2,3}.earthlink.net servers.
I will check periodically for their fixing of the zone and then remove
the forward zone in the caching servers.
Is there a simple tool to quickly identify this kind of issue? I would
prefer to cron up a job to run periodically and when the problem is
resolved to shoot me an email so I can remove the aforementioned
config.
Thanks again!
On Thu, 2011-03-03 at 16:06 -0800, Chris Buxton wrote:
> It's because the NS RRSet returned by the authoritative name servers lists
> servers that are not authoritative. Classic DNS mistake.
>
> The com zone says that the authoritative servers for supernet.com are
> ns{2,3}.earthlink.net (delegation).
>
> But supernet.com as hosted on ns{2,3}.earthlink.net says that
> dns{1,2}.earthlink.net are the authoritative servers. This latter set of
> servers is not actually authoritative for the zone.
>
> For the first query, the resolver has not yet talked to the authoritative
> servers, so its only information is the delegation NS record set from com.
> The answer to that query, however, contains the authoritative NS record set,
> which is considered more credible and therefore replaces the delegation
> record set in the resolver's cache. Subsequent queries into the zone go to
> the bad servers, get lame responses, and fail.
>
> Unless you own supernet.com, this problem is not your fault and not for you
> to fix. You can work around it with conditional forwarding, or a zone of type
> static-stub if you're using BIND 9.8 already, but that's strictly a
> workaround and subject to breakage if the zone is moved.
>
> Chris Buxton
> BlueCat Networks
>
> On Mar 3, 2011, at 2:29 PM, Justin Krejci wrote:
>
> > When doing a recursive query for MX supernet.com against a caching BIND
> > server, the BIND server responds back with the answer. The TTL is 300.
> >
> > After the TTL expires the following recursive query for the same record
> > returns a SERVFAIL from the caching server.
> >
> > If I do a +trace on the same query to the same caching server for the
> > same data it is able to respond with the answer yet a standard recursive
> > query still gives a SERVFAIL.
> >
> > Queries for other domains are working fine on this caching server. Other
> > 3rd party DNS caching servers are responding fine for the same record
> > above even after the TTL expires, tried @8.8.8.8 and @208.67.220.220
> >
> > If if flush the cache on the caching server it successfully returns the
> > answer to the query but only for the up the TTL's life then goes back to
> > SERVFAIL again. (tried doing a full stop-and-start of named as well).
> >
> > This particular server is running BIND 9.7.0-P2 but this exact same
> > behavior is also happening on a server running 9.5.1-P2.1 as well.
> >
> > So I noticed when doing a trace that the NS servers are different
> > between the gtld and the actual authoritative servers.
> >
> >
> > com.172800 IN NS l.gtld-servers.net.
> > com.172800 IN NS e.gtld-servers.net.
> > ;; Received 502 bytes from 192.36.148.17#53(i.root-servers.net) in 2987
> > ms
> >
> > supernet.com. 172800 IN NS ns2.earthlink.net.
> > supernet.com. 172800 IN NS ns3.earthlink.net.
> > ;; Received 111 bytes from 192.54.112.30#53(h.gtld-servers.net) in 119
> > ms
> >
> > supernet.com. 300 IN MX 5
> > onemain-mx.earthlink.net.
> > supernet.com. 3600IN NS dns1.earthlink.net.
> > supernet.com. 3600IN NS dns2.earthlink.net.
> > ;; Received 172 bytes from 207.217.120.43#53(ns3.earthlink.net) in 54 ms
> >
> >
> >
> > Is this just a bug that upgrading BIND will fix or is there something
> > else going on here?
> >
> > ___
> > 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: Help with unresolvable domain (subdomain, actually)
In message , John Wobus write s: > >> Then the load balancer should return default records or 0.0.0.0/:: to > >> indicate the name is good but doesn't currently have a address. > > I like that solution, actually. Even if the client doesn't recognize > > it > > as a "special" address, hopefully if it tries to connect to it, the > > packet won't make it past the first router or switch hop... > > > > Has anyone proposed this to the load-balancer vendors? > > Isn't this just a specific instance of configuring a load balancer's > fallback address? E.g., when server A and B are both down, give > address of > server C. Some load balancers allow configuration of a server D to > be used only if C is down as well. Address C or D could be configured > to be 0.0.0.0 and configured with no test for "up-ness". > > (Not that I'm completely happy with 0.0.0.0 or any other address that > local folks could conceivably have figured out some crazy use for.) 0.0.0.0, means I don't know my address. If you see packets on the wire with 0.0.0.0, which you do at boot time, the machine that sent them doesn't know its IP address yet. > John > ___ > 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
Re: Slaves and views
On 04.03.11 11:46, John Wobus wrote: > Can a zone file a slave in one view and the same zone file > be served by another view? in fact, yes. but it apparently won't work as you'd expect. > I'm going to split our authoritative servers into internal > and external views. My question concerns zones that we > secondary for other organizations, slaved to masters at > their sites. why? -- 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. If Barbie is so popular, why do you have to buy her friends? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Mar 4, 2011, at 8:46 AM, John Wobus wrote: > Hi, > > Can a zone file a slave in one view and the same zone file > be served by another view? You can do this for static master zones, but it's not a good idea for slaves. Depending on the use case for your internal view, you may be able to solve this better using forwarding, stub zones, or (BIND 9.8 only) static-stub zones. This would require that your internal view only get recursive queries, however. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On Fri, 2011-03-04 at 11:46 -0500, John Wobus wrote: > Hi, > > Can a zone file a slave in one view and the same zone file > be served by another view? It is a bad idea, although I know (from experience) it will work for static zones. One problem is you need to remember to reload the zone in both views if you make any changes to it. Again, it is a bad idea and I think ISC recommends against it. > I'm not (yet) worried about dynamic updates, if there are > any. That will not work. You will need separate files for each view. Steve. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
On 3/4/2011 11:46 AM, John Wobus wrote: > I'm going to split our authoritative servers into internal > and external views. Is there anything I can do to try to talk you out of doing this? AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Slaves and views
Haven't done it but don't see why not. Since every entry in named.conf specifies the zone file you can definitely have multiple zones all pointing to the same zone file. (We do that for many ancillary zones that we want to point to our primary domain so have an aliases file that uses the @ designation instead of hard coded domain names.) -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of John Wobus Sent: Friday, March 04, 2011 11:46 AM To: bind-users Subject: Slaves and views Hi, Can a zone file a slave in one view and the same zone file be served by another view? I'm going to split our authoritative servers into internal and external views. My question concerns zones that we secondary for other organizations, slaved to masters at their sites. I know I could configure each of their zones with separate files in each the two views, listen/use an additional address that accesses our local view, and tell these peer organizations to notify and allow transfers from this additional address. I'm not (yet) worried about dynamic updates, if there are any. Is there a way I can handle their zones without making these other sites configure another address, and I still run just one bind instance? Other ideas are: running a separate bind instance for these zones, or making one view a slave to the other. Possibly forwarding of some kind, another thing I haven't done much. John Wobus Cornell ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Slaves and views
Hi, Can a zone file a slave in one view and the same zone file be served by another view? I'm going to split our authoritative servers into internal and external views. My question concerns zones that we secondary for other organizations, slaved to masters at their sites. I know I could configure each of their zones with separate files in each the two views, listen/use an additional address that accesses our local view, and tell these peer organizations to notify and allow transfers from this additional address. I'm not (yet) worried about dynamic updates, if there are any. Is there a way I can handle their zones without making these other sites configure another address, and I still run just one bind instance? Other ideas are: running a separate bind instance for these zones, or making one view a slave to the other. Possibly forwarding of some kind, another thing I haven't done much. John Wobus Cornell ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
Dnia 2011-03-04 23:07 terry napisał(a): >> Look at RA and RD. If the server recurses, you will get a answer. >> If the server does not recurse, you will get a referral. Then there >> are the really old broken servers which get this wrong. >> > >Hi Mark, > >Please see this for details: > >$ dig nsbeta.info ns @ns34.domaincontrol.com > >; <<>> DiG 9.4.2-P2.1 <<>> nsbeta.info ns @ns34.domaincontrol.com >;; global options: printcmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41454 >;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >;; WARNING: recursion requested but not available > >;; QUESTION SECTION: >;nsbeta.info. IN NS > >;; ANSWER SECTION: >nsbeta.info.3600IN NS ns34.domaincontrol.com. >nsbeta.info.3600IN NS ns33.domaincontrol.com. > > >There isn't the "ra" flag in the response, why the nameserver has been >also answering with the "ANSWER SECTION"? I think it should answer >with the "AUTHORITY SECTION". But in this case, you're asking the authotrative server. Authorative server answers in answer section, as it knows the answer. Authorative section is for 'I don't know, ask ...' The rule above goes for servers which are not authorative for a given zone. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
Then the load balancer should return default records or 0.0.0.0/:: to indicate the name is good but doesn't currently have a address. I like that solution, actually. Even if the client doesn't recognize it as a "special" address, hopefully if it tries to connect to it, the packet won't make it past the first router or switch hop... Has anyone proposed this to the load-balancer vendors? Isn't this just a specific instance of configuring a load balancer's fallback address? E.g., when server A and B are both down, give address of server C. Some load balancers allow configuration of a server D to be used only if C is down as well. Address C or D could be configured to be 0.0.0.0 and configured with no test for "up-ness". (Not that I'm completely happy with 0.0.0.0 or any other address that local folks could conceivably have figured out some crazy use for.) John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
2011/3/4 Mark Andrews : > > In message , > terr > y writes: >> Hello, >> >> When I delegate a subdomain in a zone example.com, the config in >> named.conf is like: >> >> test.example.com. 3600 IN NS ns1.another.com. >> test.example.com. 3600 IN NS ns2.another.com. >> >> Then I dig to the auth-server of the example zone: >> >> dig test.example.com ns @ns1.example.com >> >> I found some servers return the ANSWER SECTION, but some servers >> return the AUTHORITY SECTION. >> >> For example: >> >> ;; ANSWER SECTION: >> test.example.com. 3600 IN NS ns2.another.com. >> test.example.com. 3600 IN NS ns1.another.com. >> >> And: >> >> ;; AUTHORITY SECTION: >> test.example.com. 3600 IN NS ns2.another.com. >> test.example.com. 3600 IN NS ns1.another.com. >> >> >> I'm confused, shall name server answer with ANSWER or AUTHORITY for this case >> ? > > Look at RA and RD. If the server recurses, you will get a answer. > If the server does not recurse, you will get a referral. Then there > are the really old broken servers which get this wrong. > Hi Mark, Please see this for details: $ dig nsbeta.info ns @ns34.domaincontrol.com ; <<>> DiG 9.4.2-P2.1 <<>> nsbeta.info ns @ns34.domaincontrol.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41454 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;nsbeta.info. IN NS ;; ANSWER SECTION: nsbeta.info.3600IN NS ns34.domaincontrol.com. nsbeta.info.3600IN NS ns33.domaincontrol.com. ;; Query time: 183 msec ;; SERVER: 208.109.255.17#53(208.109.255.17) ;; WHEN: Fri Mar 4 22:59:39 2011 ;; MSG SIZE rcvd: 123 There isn't the "ra" flag in the response, why the nameserver has been also answering with the "ANSWER SECTION"? I think it should answer with the "AUTHORITY SECTION". Thanks again. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
In message , terr y writes: > Hello, > > When I delegate a subdomain in a zone example.com, the config in > named.conf is like: > > test.example.com. 3600 IN NS ns1.another.com. > test.example.com. 3600 IN NS ns2.another.com. > > Then I dig to the auth-server of the example zone: > > dig test.example.com ns @ns1.example.com > > I found some servers return the ANSWER SECTION, but some servers > return the AUTHORITY SECTION. > > For example: > > ;; ANSWER SECTION: > test.example.com. 3600IN NS ns2.another.com. > test.example.com. 3600IN NS ns1.another.com. > > And: > > ;; AUTHORITY SECTION: > test.example.com. 3600IN NS ns2.another.com. > test.example.com. 3600IN NS ns1.another.com. > > > I'm confused, shall name server answer with ANSWER or AUTHORITY for this case > ? Look at RA and RD. If the server recurses, you will get a answer. If the server does not recurse, you will get a referral. Then there are the really old broken servers which get this wrong. Mark > Thanks in advance. > ___ > 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
about AUTHORITY SECTION
Hello, When I delegate a subdomain in a zone example.com, the config in named.conf is like: test.example.com. 3600 IN NS ns1.another.com. test.example.com. 3600 IN NS ns2.another.com. Then I dig to the auth-server of the example zone: dig test.example.com ns @ns1.example.com I found some servers return the ANSWER SECTION, but some servers return the AUTHORITY SECTION. For example: ;; ANSWER SECTION: test.example.com. 3600IN NS ns2.another.com. test.example.com. 3600IN NS ns1.another.com. And: ;; AUTHORITY SECTION: test.example.com. 3600IN NS ns2.another.com. test.example.com. 3600IN NS ns1.another.com. I'm confused, shall name server answer with ANSWER or AUTHORITY for this case? Thanks in advance. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
