f



Re: "Empty zones" and BIND 9.4 #4

> Mark Andrews wrote:
> >> For the loopback subnet reverse zone, if you want to create a PTR
> >> record for each possible IP, use a wildcard. So instead of this from
> >> Mark's example:
> >>
> >> 1.0.0 PTR localhost.
> >>
> >> use this:
> >>
> >> *     PTR localhost.
> >>
> >> Chris Buxton
> >> Men & Mice
> >
> > Normally you only need "1.0.0 PTR localhost." as that
> > is usually the only address in use.
> >
> > If you don't use it then you don't need a PTR.  If you do
> > use it but forget the PTR then you want to stop the query
> > leaking so that why the zone is 127.IN-ADDR.ARPA and not
> > 1.0.0.127.IN-ADDR.ARPA, 0.0.127.IN-ADDR.ARPA or 0.127.IN-ADDR.ARPA.
> > NXDOMAIN will be returned if there is no PTR record.
> 
> Maye I'm confused, but why is it 0.0.127.IN-ADDR.ARPA cannot be used? 
> Why/how would that cause "query leaking" (and what is that exactly?)

	If you use address 127.1.1.1 and do a reverse lookup on it
	then it is will not be answered from 0.0.127.IN-ADDR.ARPA.
	The query instead will go to the IN-ADDR.ARPA servers and
	a NXDOMAIN will be returned.  The query is supposed to be
	answered locally and 127/8 is a purely local resource.
 
> I guess I jsut want to understand the logic & reasoning behind all this.
> 
> > Additionally the PTR from the wildcard will be rejected by
> > may applications / libraries as there is not a corresponding
> > A record.
> 
> Wouldn't it just map ever IP that starts with 127. to localhost? How 
> would that break anything? Looking up, say, 127.0.0.21 would yield 
> localhost, would it not? Sorry, I just don't see how this could be a 
> problem.

	localhost has a well known values (127.0.0.1 and ::1).
	To make "21.0.0.127.IN-ADDR.ARPA PTR localhost." effective
	you need to have a "localhost A 127.0.0.21" record on the
	search path.  Lookups for localhost would then return
	127.0.0.1, 127.0.0.21 and ::1.  Not all applictions will
	cope well with this especially as 127.0.0.21 may not exist
	on all the machines that get this answer.
 
> -- 
> CL
> 
> > I DO NOT recommend adding all the possible A records in this
> > space.  It will only cause applications to break.
> >
> > Mark
> >
> >> On Jun 18, 2007, at 7:33 AM, Mark Andrews wrote:
> >>
> >>>
> >>>> Hi all,
> >>>>
> >>>> There was big discussion about empty-zones feature in BIND >= 9.4
> >>>> on Red
> >>>> Hat's bugzilla. We have found two problems around this.
> >>>>
> >>>> - RFC 3330 says that loopback could be 127/8. Does anybody here
> >>>> know how
> >>>> configure 127.in-addr.arpa. zone as described in RFC? $GENERATE
> >>>> directive isn't sufficient for solve this problem.
> >>>
> >>> Why would one want to use $GENERATE.
> >>>
> >>> zone "127.IN-ADDR.ARPA" {
> >>> };
> >>>
> >>> @ SOA ..
> >>> @ NS ..
> >>> 1.0.0 PTR localhost.
> >>>
> >>>> - RFC 2181, section 7.3 tells about MNAME record in SOA. It's name
> >>>> of primary server. All empty zones returns name of zone instead
> >>>> primary nameserver (could be "localhost.")
> >>>
> >>> No.  It's the name of the primary (only) nameserver.  It just
> >>> happens to be the name of the zone as well.  The zone names
> >>> are all legal hostnames.
> >>>
> >>> draft-ietf-dnsop-default-local-zones-02.txt
> >>>
> >>> There are also named.conf options to change what is returned.
> >>>
> >>>> Thanks for any hints,
> >>>> Adam
> >>> --
> >>> Mark Andrews, ISC
> >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>> PHONE: +61 2 9871 4742                 INTERNET:
> >>> Mark_Andrews@isc.org
> >>>
> >>>
> >>
> >>
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org


0
Mark
6/20/2007 8:47:42 PM
comp.protocols.dns.bind 16245 articles. 1 followers. Post Follow

3 Replies
604 Views

Similar Articles

[PageSpeed] 57

Mark Andrews wrote:
>> Mark Andrews wrote:
>>>> For the loopback subnet reverse zone, if you want to create a PTR
>>>> record for each possible IP, use a wildcard. So instead of this
>>>> from Mark's example:
>>>>
>>>> 1.0.0 PTR localhost.
>>>>
>>>> use this:
>>>>
>>>> *     PTR localhost.
>>>>
>>>> Chris Buxton
>>>> Men & Mice
>>>
>>> Normally you only need "1.0.0 PTR localhost." as that
>>> is usually the only address in use.
>>>
>>> If you don't use it then you don't need a PTR.  If you do
>>> use it but forget the PTR then you want to stop the query
>>> leaking so that why the zone is 127.IN-ADDR.ARPA and not
>>> 1.0.0.127.IN-ADDR.ARPA, 0.0.127.IN-ADDR.ARPA or 0.127.IN-ADDR.ARPA.
>>> NXDOMAIN will be returned if there is no PTR record.
>>
>> Maye I'm confused, but why is it 0.0.127.IN-ADDR.ARPA cannot be used?
>> Why/how would that cause "query leaking" (and what is that exactly?)
>
> If you use address 127.1.1.1 and do a reverse lookup on it
> then it is will not be answered from 0.0.127.IN-ADDR.ARPA.
> The query instead will go to the IN-ADDR.ARPA servers and
> a NXDOMAIN will be returned.  The query is supposed to be
> answered locally and 127/8 is a purely local resource.
>
>> I guess I jsut want to understand the logic & reasoning behind all
>> this.
>>
>>> Additionally the PTR from the wildcard will be rejected by
>>> may applications / libraries as there is not a corresponding
>>> A record.
>>
>> Wouldn't it just map ever IP that starts with 127. to localhost? How
>> would that break anything? Looking up, say, 127.0.0.21 would yield
>> localhost, would it not? Sorry, I just don't see how this could be a
>> problem.
>
> localhost has a well known values (127.0.0.1 and ::1).
> To make "21.0.0.127.IN-ADDR.ARPA PTR localhost." effective
> you need to have a "localhost A 127.0.0.21" record on the
> search path.  Lookups for localhost would then return
> 127.0.0.1, 127.0.0.21 and ::1.  Not all applictions will
> cope well with this especially as 127.0.0.21 may not exist
> on all the machines that get this answer.


Well, wouldn't be better to have the '* IN PTR localhost' and just have 
'localhost IN A 127.0.0.1', that way localhost resolves to 127.0.0.1 
like expected and 127.0.0.1 (any anything else 127.*) comes back as 
localhost, as all 127/8 addresses are technically "localhost" addresses?

-- 
CL



>>> I DO NOT recommend adding all the possible A records in this
>>> space.  It will only cause applications to break.
>>>
>>> Mark
>>>
>>>> On Jun 18, 2007, at 7:33 AM, Mark Andrews wrote:
>>>>
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> There was big discussion about empty-zones feature in BIND >= 9.4
>>>>>> on Red
>>>>>> Hat's bugzilla. We have found two problems around this.
>>>>>>
>>>>>> - RFC 3330 says that loopback could be 127/8. Does anybody here
>>>>>> know how
>>>>>> configure 127.in-addr.arpa. zone as described in RFC? $GENERATE
>>>>>> directive isn't sufficient for solve this problem.
>>>>>
>>>>> Why would one want to use $GENERATE.
>>>>>
>>>>> zone "127.IN-ADDR.ARPA" {
>>>>> };
>>>>>
>>>>> @ SOA ..
>>>>> @ NS ..
>>>>> 1.0.0 PTR localhost.
>>>>>
>>>>>> - RFC 2181, section 7.3 tells about MNAME record in SOA. It's
>>>>>> name of primary server. All empty zones returns name of zone
>>>>>> instead primary nameserver (could be "localhost.")
>>>>>
>>>>> No.  It's the name of the primary (only) nameserver.  It just
>>>>> happens to be the name of the zone as well.  The zone names
>>>>> are all legal hostnames.
>>>>>
>>>>> draft-ietf-dnsop-default-local-zones-02.txt
>>>>>
>>>>> There are also named.conf options to change what is returned.
>>>>>
>>>>>> Thanks for any hints,
>>>>>> Adam



0
Clenna
6/20/2007 9:46:39 PM
In article <f5c7k9$2icm$1@sf1.isc.org>,
 "Clenna Lumina" <savagebeaste@yahoo.com> wrote:

> Well, wouldn't be better to have the '* IN PTR localhost' and just have 
> 'localhost IN A 127.0.0.1', that way localhost resolves to 127.0.0.1 
> like expected and 127.0.0.1 (any anything else 127.*) comes back as 
> localhost, as all 127/8 addresses are technically "localhost" addresses?

If you're using other 127.x.x.x addresses, they're probably intended for 
specific purposes, not the generic loopback.  So you should probably 
create application-specific forward and reverse records for them, rather 
than mapping them all to "localhost".

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***


0
Barry
6/21/2007 1:32:08 AM
Barry Margolin wrote:
> In article <f5c7k9$2icm$1@sf1.isc.org>,
>  "Clenna Lumina" <savagebeaste@yahoo.com> wrote:
> 
>> Well, wouldn't be better to have the '* IN PTR localhost' and just have 
>> 'localhost IN A 127.0.0.1', that way localhost resolves to 127.0.0.1 
>> like expected and 127.0.0.1 (any anything else 127.*) comes back as 
>> localhost, as all 127/8 addresses are technically "localhost" addresses?
> 
> If you're using other 127.x.x.x addresses, they're probably intended for 
> specific purposes, not the generic loopback.  So you should probably 
> create application-specific forward and reverse records for them, rather 
> than mapping them all to "localhost".
> 

NTP uses 127.127.x.x for refclock references.

Danny


0
Danny
6/23/2007 12:24:58 AM
Reply:

Similar Artilces:

Re: "Empty zones" and BIND 9.4
> Hi all, > > There was big discussion about empty-zones feature in BIND >= 9.4 on Red > Hat's bugzilla. We have found two problems around this. > > - RFC 3330 says that loopback could be 127/8. Does anybody here know how > configure 127.in-addr.arpa. zone as described in RFC? $GENERATE > directive isn't sufficient for solve this problem. Why would one want to use $GENERATE. zone "127.IN-ADDR.ARPA" { }; @ SOA .. @ NS .. 1.0.0 PTR localhost. > - RFC 2181, section 7.3 tells about MNAME record in SOA. It's name of > primary server. All empty zones returns name of zone instead primary > nameserver (could be "localhost.") No. It's the name of the primary (only) nameserver. It just happens to be the name of the zone as well. The zone names are all legal hostnames. draft-ietf-dnsop-default-local-zones-02.txt There are also named.conf options to change what is returned. > Thanks for any hints, > Adam -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org ...

Re: "Empty zones" and BIND 9.4 #2
> For the loopback subnet reverse zone, if you want to create a PTR > record for each possible IP, use a wildcard. So instead of this from > Mark's example: > > 1.0.0 PTR localhost. > > use this: > > * PTR localhost. > > Chris Buxton > Men & Mice Normally you only need "1.0.0 PTR localhost." as that is usually the only address in use. If you don't use it then you don't need a PTR. If you do use it but forget the PTR then you want to stop the query leaking so that why the zone is 127.IN-ADDR.ARPA and not 1.0.0.127.IN-ADDR.ARPA, 0.0.127.IN-ADDR.ARPA or 0.127.IN-ADDR.ARPA. NXDOMAIN will be returned if there is no PTR record. Additionally the PTR from the wildcard will be rejected by may applications / libraries as there is not a corresponding A record. I DO NOT recommend adding all the possible A records in this space. It will only cause applications to break. Mark > On Jun 18, 2007, at 7:33 AM, Mark Andrews wrote: > > > > >> Hi all, > >> > >> There was big discussion about empty-zones feature in BIND >= 9.4 > >> on Red > >> Hat's bugzilla. We have found two problems around this. > >> > >> - RFC 3330 says that loopback could be 127/8. Does anybody here > >> know how > >> configure 127.in-addr.arpa. zone as described in RFC? $GENERATE >...

Re: "Empty zones" and BIND 9.4 #5
> Mark Andrews wrote: > >> Mark Andrews wrote: > >>>> For the loopback subnet reverse zone, if you want to create a PTR > >>>> record for each possible IP, use a wildcard. So instead of this > >>>> from Mark's example: > >>>> > >>>> 1.0.0 PTR localhost. > >>>> > >>>> use this: > >>>> > >>>> * PTR localhost. > >>>> > >>>> Chris Buxton > >>>> Men & Mice > >>> > >>> Normally you only need "1.0.0 PTR localhost." as that > >>> is usually the only address in use. > >>> > >>> If you don't use it then you don't need a PTR. If you do > >>> use it but forget the PTR then you want to stop the query > >>> leaking so that why the zone is 127.IN-ADDR.ARPA and not > >>> 1.0.0.127.IN-ADDR.ARPA, 0.0.127.IN-ADDR.ARPA or 0.127.IN-ADDR.ARPA. > >>> NXDOMAIN will be returned if there is no PTR record. > >> > >> Maye I'm confused, but why is it 0.0.127.IN-ADDR.ARPA cannot be used? > >> Why/how would that cause "query leaking" (and what is that exactly?) > > > > If you use address 127.1.1.1 and do a reverse lookup on it > > then it is will not be answered from 0.0.127.IN-ADDR.ARPA. >...

Re: "Empty zones" and BIND 9.4 #3
> >> Normally you only need "1.0.0 PTR localhost." as that > >> is usually the only address in use. > > There are lots of applications that need multiple ip-addresses. > There are portable hosts connected or not - with ever changing > ip-addresses. > > e.g. djbdns > > For whatever reason you want to run your own copy of the root. > So you run tinydns on 127.0.1.229 as rootserver and > dnscache on 127.0.2.229 and maybe > your own imapd on 127.0.3.229. > > Localhost is still 127.0.0.1. > > It works and I have seen it on many portables. > > You cannot use an 192.168... on the lan or wlan because > both of them get disconnected and both of them keep changing. > > On my laptop bind 9.4.0 is running on 127.0.8.229 and collecting > data for the other nameservers. > > Of course bind "knows" all those 127... addresses and answers > queries for them. Peter, how was this productive to the discussion? "usually the only address in use" does not preclude the use of other addresses. I use other addresses under 127/8 myself but I am also atypical in this respect. The discussion was what to name these other addresses and I was saying don't name them "localhost". Mark > Kind regards > Peter and Karin > > -- > Peter and Karin Dambier > Cesidian Root - Radice Cesidiana > Rimb...

"Empty zones" and BIND 9.4
Hi all, There was big discussion about empty-zones feature in BIND >= 9.4 on Red Hat's bugzilla. We have found two problems around this. - RFC 3330 says that loopback could be 127/8. Does anybody here know how configure 127.in-addr.arpa. zone as described in RFC? $GENERATE directive isn't sufficient for solve this problem. - RFC 2181, section 7.3 tells about MNAME record in SOA. It's name of primary server. All empty zones returns name of zone instead primary nameserver (could be "localhost.") Thanks for any hints, Adam ...

Re: BIND 9.4.1-P1: "allow-query" and "allow-query-cache"
> I've recently gotten around to upgrading from BIND 8.3.7-REL to BIND > 9.4.1-P1. I would like to have a better understanding of the "allow- > query" and "allow-query-cache" options. > > Assuming that I have "allow-query { any; };" and "allow-query-cache > { none; };" set in the global options for a name server, what > information can an external system access on the name server? > > I presume that the external system can access information regarding > any zone defined as "type master;". Does this hold true when there > are no NS resource records identifying the name server as > authoritative for the zone? > > Can external systems access information regarding any zone defined as > "type slave;"? Again, does this hold true when there are no NS > resource records identifying the name server as authoritative for the > zone? master/slave zones inherit allow-query from the options / view level. I presume you mean no delegation to these servers rather than no NS records as the zones won't load without NS record. Lack of delegation has no impact on whether named will answer for the zone or not. Only the contents of named.conf control that. > What information is accessible for zones defined as "type stub;" and > "type forward;"? Stub zones prime the cache, forward zones...

BIND 9.4.1-P1: "allow-query" and "allow-query-cache"
I've recently gotten around to upgrading from BIND 8.3.7-REL to BIND 9.4.1-P1. I would like to have a better understanding of the "allow- query" and "allow-query-cache" options. Assuming that I have "allow-query { any; };" and "allow-query-cache { none; };" set in the global options for a name server, what information can an external system access on the name server? I presume that the external system can access information regarding any zone defined as "type master;". Does this hold true when there are no NS resource records identifying the name server as authoritative for the zone? Can external systems access information regarding any zone defined as "type slave;"? Again, does this hold true when there are no NS resource records identifying the name server as authoritative for the zone? What information is accessible for zones defined as "type stub;" and "type forward;"? Merton Campbell Crockett m.c.crockett@roadrunner.com ...

Re: "malformed transaction" Message BIND 9.5.0 #4
>> I wrote: >> >> >> I upgraded to BIND 9.5.0 earlier this week, and after the upgrade I >> >> see a message on one of my BIND 9.5.0 servers: >> >> >> >> Jun 25 09:44:00 puck.it.anl.gov named[20168]: >> >> [ID 873579 daemon.error] malformed transaction: >> >> cmt227.rev.jnl last serial 6843 != transaction first serial 6842 >> >> >> >> I am looking at the logs, dns traces, and snoop traces now. I have not >> >> yet concluded what is happening. To what address should I send my >> >> files and summaries? Thanks. >> >> and Mark Andrews replied: >> >> > Did you remove the old (possibly corrupted) journal files when >> > you upgraded? >> >> I did not remove the jnl files when I upgraded. I have looked at the >> various pieces of documentation and I see on puck: >> >> Jun 25 09:43:18 puck.it.anl.gov named[20168]: [ID 873579 daemon.info] >> zone 227.139.146.in-addr.arpa/IN/external: transferred serial 6843 >> Jun 25 09:43:18 puck.it.anl.gov named[20168]: [ID 873579 daemon.info] >> transfer of '227.139.146.in-addr.arpa/IN/external' >> from 146.137.64.5#53: Transfer completed: 1 messages, 6 records, >> 260 bytes, 0.073 secs (3561 bytes/sec) >> >> Then I see o...

"controls" statement not checked for correctness by "named-checkconf" in BIND 9.3.4-P1.1
Hello. I just wanted to bring it to your notice that: The named-checkconf that came with my bind9 package does not check for the correctness of the following statement in my named.conf include "/etc/bind/keys/rndc.key"; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; where "/etc/bind/keys/rndc.key"; key "rndc-key" { algorithm hmac-md5; secret "AHsEhqnijULBSnJ3BHg9eQ=="; }; SEE THE "_" and "-" in controls and key statements, respectively. However, "named-c...

Re: named-checkzone 9.4.1-P1 appears to treat "out of zone" as "CNAME (illegal)"
> The named-checkzone utility from BIND 9.4.1-P1 is giving me unexpected > and apparently bogus warnings. It seems to be treating ALL out-of-one > targets in NS and MX records as if they were references to CNAMEd > names. > > This looks to me like a bug. > > We always download the tarball from ISC and install BIND from that. > > Here are the results from named-checkzone. > > keadeen(noreilly)111: named-checkzone ucd.ie tmp/ucd.ie.dummy-zone > zone ucd.ie/IN: hermes.ucd.ie/MX 'relay.esat.net' (out of zone) is a > CNAME (illegal) > zone ucd.ie/IN: www.ucd.ie/NS 'beaker.heanet.ie' (out of zone) is a > CNAME (illegal) > zone ucd.ie/IN: www.ucd.ie/NS 'bunsen.heanet.ie' (out of zone) is a > CNAME (illegal) > zone ucd.ie/IN: loaded serial 2007103106 > OK > keadeen(noreilly)112: getaddrinfo() returned a different name in ai_canonname to relay.esat.net when the address of relay.esat.net was looked up. I'll make named-checkzone report the name returned. Mark Index: bin/check/check-tool.c =================================================================== RCS file: /proj/cvs/prod/bind9/bin/check/check-tool.c,v retrieving revision 1.10.18.18 diff -u -r1.10.18.18 check-tool.c --- bin/check/check-tool.c 13 Sep 2007 05:04:01 -0000 1.10.18.18 +++ bin/check/check-tool.c 31 Oct 2007 22:55:45 -0000 @@ -142,8 +142,8 @@ strcasecmp(a...

RE: BIND 9.6 Flaw
The authoritative name servers for nullmx.domainmanager.com are ns1.domainmanager.com and ns2.domainmanager.com. They are domain parking name servers. They return 64.40.103.249 (or at least something close to that) to the query for any A record. The real address of mta.dewile.net is 69.59.189.80 (as supplied by ns1.alices-registry.com, one of the authoritative name servers for "dewile.net"). > -----Original Message----- > From: bind-users-bounces@lists.isc.org > [mailto:bind-users-bounces@lists.isc.org] On Behalf Of Al Stu > Sent: Friday, January 30, 20...

Re: BIND 9.6 Flaw
In message <3C802402A28C4B2390B088242A91FB9C@AHSNBW1>, "Al Stu" writes: > > RFC 974: > "There is one other special case. If the response contains an answer which > is a CNAME RR, it indicates that REMOTE is actually an alias for some other > domain name. The query should be repeated with the canonical domain name." And that is talking about the response to a MX query. The section from which you quote starts with: Issuing a Query The first step for the mailer at LOCAL is to issue a query for MX RRs for REMOTE. It is strongl...

Re: "out of zone data" with bind-9.3.2
> Hi, > > I have recently upgraded my bind to bind-9.3.2 from bind-9.2. However, > when I start the daemon I now get a lot of out of zone data messages > which I didn't before. > > The way I have it configured is I have one zone, but 4 subdomains. The > hosts in these subdomains are in seperate files, and are added to the > main zones' records with include directives. The top of the each of > these files contains an $origin statement. > > so it looks like this. > > main file. > > $include Header < SOA record &g...

Re: BIND 9.4.x empty zones
> I have been looking at the new "built-in empty zone" stuff in 9.4.x > (specific experiments with 9.4.2rc1), partly with a view to getting > our production 9.3.x setup in line so that the transition is not too > traumatic. Comparing them with the "server information" (class CHAOS) > "version.bind" zone and friends is also instructive. You may want to look at the draft-ietf-dnsop-default-local-zones drafts and discussions in the dnsop working group. > Here is a summary of what I have found so far, with some questions > arising. > > 1. SOA.mname (and single NS record) has the same name as the zone > (modifiable for the empty-zones by the "empty-server" option, > fixed for the server-info zones). Does this actually make sense? > Maybe it's just harmless. The default is answered by the empty zone itself. > 2. SOA.rname is "." for empty-zones (modifiable by the "empty-contact" > option) but "hostmaster.[zone-name]" for the server-info zones > (not modifiable). I actually rather like the idea of "." as > indicating "there isn't any contact address, get lost", but can > that be justified from the RFCs? There was lots of discussion over this one. > 3. The remaining SOA parameters are fixed at "0 28800 7200 604800 86400" > for both sorts of zones. I...

RE: Re: Migration from BIND 4.9 to 9.2 or Microsoft DNS
Hi Sorry for the misunderstanding I was not looking for support, I was just asking from people, who have been in the same situation that I am in now What influenced their decision to choose what ever they chose to go with -----Original Message----- From: bind-users-bounce@isc.org [mailto:bind-users-bounce@isc.org] On Behalf Of phn@icke-reklam.ipsec.nu Sent: 11 October 2004 21:21 To: comp-protocols-dns-bind@isc.org Subject: Re: Migration from BIND 4.9 to 9.2 or Microsoft DNS Mokwena Motseto <MotsetM@sapo.co.za> wrote: > Hi > We are currently running BIND 4...

named-checkzone 9.4.1-P1 appears to treat "out of zone" as "CNAME (illegal)"
The named-checkzone utility from BIND 9.4.1-P1 is giving me unexpected and apparently bogus warnings. It seems to be treating ALL out-of-one targets in NS and MX records as if they were references to CNAMEd names. This looks to me like a bug. We always download the tarball from ISC and install BIND from that. Here are the results from named-checkzone. keadeen(noreilly)111: named-checkzone ucd.ie tmp/ucd.ie.dummy-zone zone ucd.ie/IN: hermes.ucd.ie/MX 'relay.esat.net' (out of zone) is a CNAME (illegal) zone ucd.ie/IN: www.ucd.ie/NS 'beaker.heanet.ie' (out of zone) is a CNAME (illegal) zone ucd.ie/IN: www.ucd.ie/NS 'bunsen.heanet.ie' (out of zone) is a CNAME (illegal) zone ucd.ie/IN: loaded serial 2007103106 OK keadeen(noreilly)112: Below is possibly relevant additional information. keadeen(noreilly)112: cat tmp/ucd.ie.dummy-zone $TTL 86400 $ORIGIN ucd.ie. @ IN SOA . sysman.ucd.ie. ( 2007103106 ; serial 14400 ; Refresh - 4 hours 7200 ; Retry - 2 hours 604800 ; Expire - 7 days 86400 ) ; Default - 1 day ; @ IN NS stealth.ucd.ie. ; $ORIGIN ucd.ie. ; www 300 IN NS beaker.heanet.ie. www 300 IN NS bunsen.heanet.ie. ...

Re: BIND 9.4.x empty zones #2
> On 31 Oct 2007, at 22:50, Chris Thompson wrote: > > > I have been looking at the new "built-in empty zone" stuff in 9.4.x > > I've been treating the warnings about these zones and about > reverse queries for RFC1918 addresses escaping onto the Internet > as prompts to clean up our act, and have begun to configure > explicitly each zone for which an "automatic" warning is otherwise > generated. > > I've noticed a couple of surprises (using 9.4.1-P1). > > 1. > The 18 zones for 10/8, 172.16/12, and 192.168/16 don't appear > to be considered for activation as "automatic empty zones", > perhaps in an attempt to avoid collisions with operational use > of addresses from some parts of these blocks. In contrast, an > automatic empty zone is activated for 127/8, even though it > collides with the traditional, and actually configured on the > same server, zone for 127.0.0.1/32. This seems inconsistent. No. They are just waiting for the draft to pass through the IETF. > Rather than silently ignoring these 18 zones, I think it would > be useful to emit a different flavour of warning, intended to > prompt the local sysadmin to consider doing the "right thing". > Relying on eventual per-query "RFC1918" warnings seems to me > to miss an opportunity for giving an early helpful prompt. > P...

BIND 9.4.3-P1 "general: socket.c:4524:" error
--===============8004002223491956850== Content-Type: multipart/alternative; boundary=001485f9456265e2ca0468066626 --001485f9456265e2ca0468066626 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi to everybody, We just installed a bind version 9.4.3-P1 at our RHEL5 64bit machine and we got this error Apr 19 17:22:09 SVPNSCACHE3 namedlstnr0-9.4.3-P1[3337]: general: socket.c:4524: unexpected error: Apr 19 17:22:09 SVPNSCACHE3 namedlstnr0-9.4.3-P1[3337]: general: 22/Invalid argument Apr 19 17:22:09 SVPNSCACHE3 namedlstnr0-9.4.3-P1[3337]: general: s...

bind 9.4.3b2 probs
Hi there, needing some input, but here's the background: I have a couple dozen recursive resolvers around the country. A mix of Sun v210's on Sol8 and T2000's on Sol10. All were running bind 9.4.2, but we built and installed 9.4.3b2 on two of each platforms (4 machines). One of the T2000's quickly became unresponsive with many of these errors: recursive-clients soft limit exceeded, aborting oldest query That machine (of the four) traditionally takes more traffic than the other three. All the other machines running 9.4.3b2 (and those on 9.4.2) run fine. We built 9.4.2-P1 and installed it on the misbehaving T2000 and it seems to run OK, but we get a few of these at times: socket: too many open file descriptors root@rns-catcall[233]# grep recurs named.conf* named.conf: recursion yes; named.conf: recursive-clients 50000; root@rns-catcall[234]# The one machine with problems on 9.4.3b2 had status values like this: recursive clients: 49800/49900/50000 and now, on 9.4.2-P1 its: recursive clients: 410/49900/50000 Our build command for 9.4.2, 9.4.2-P1 and 9.4.3b2 were all the same: ./configure --prefix=/ms/svc/dns --enable-threads --disable-ipv6 --disable-linux-caps --with-randomdev=/dev/urandom - -without-kame --sysconfdir=/ms/svc/dns/etc --localstatedir=/ms/var --mandir=/ms/man && MAKE The only other thing we had to do to get 9.4.3b2 running was to mknod /dev/poll in our chroot. What do you thi...

Bind 9.9.1 forward zone "local"
--047d7bd7625e318f6404f5721486 Content-Type: text/plain; charset=ISO-8859-1 Hello. I have a problem with forwarding zone "local" to ISP resolvers. My config is: options { directory "/tmp"; disable-empty-zone "."; }; zone "." { type slave; masters { 192.0.32.132; 193.0.14.129;}; masterfile-format text; file "/etc/bind/db.root"; allow-query { any; }; }; zone "local." IN { type forward; forwarders {DNS_IP_ISP;}; forward only; }; zo...

Re: What's wrong with this: street_n=addr1_1|" "||addr2||" "||addr3||" "||addr4||" "||addr5 #4
Thank you for the code. That's what I really wanted to see. I have some problem in understanding the code: particularly, ` '0'* <^w ?*> from your code rx = rxparse("` '0'* <^w ?*> to =1"); I know the tag expression and *, but I do not understand the rest characters. Can you explain it for me? Many thanks, Duckhye >>> "Chang Y. Chung" <chang_y_chung@HOTMAIL.COM> 03/04/04 01:36PM >>> On Thu, 4 Mar 2004 12:55:20 -0600, Duck-Hye Yang <dyang@CHAPINHALL.ORG> wrote: >Hi, >I wanted to remove the first zero ...

RE: "continue/next" for "loop" #4
"Sometimes I use exceptions..." I remember some people are against using exceptions for control flow. I = think this even appears in some coding standards. So, as other have said, the goto might be appropriate. Yet another way is to structure the code more, i.e. put the crucial = sequences of statements inside (local) procedures, and then call the = procedures at the appropriate points. Of course you may have to parametrize the procedures to pass the values = of the loop control variables. Come to think of it, this is probably how I do it most of the times. I = seem to remember ...

bind 9.4 and bind 9.5 works in BSD/OS 4.3.X
Found the answer and any early OS should adapt the following: Check to see if you have an /etc/login.conf file If so check for any parameter that has openfiles-cur Set to 1024 or higher and that should get bind 9.4 + working . -- Member - Liberal International This is doctor@nl2k.ab.ca Ici doctor@nl2k.ab.ca God, Queen and country! Never Satan President Republic! Beware AntiChrist rising! http://twitter.com/rootnl2k http://www.myspace.com/502748630 Merry Christmas 2009 and Happy New Year 2010 ...

Re: bind 8.4.5
> Hello. > > I'm running BIND 8.4.5 on HPUX 11i, > and everytime I reboot the system, > logs like these appears on ch_panic.log ... > > "ch_panic.log" 14 lines, 1092 characters > 18-Oct-2004 19:16:57.329 panic: critical: getifaddrs: Operation not supported > 18-Oct-2004 19:16:59.383 panic: critical: getifaddrs: Operation not supported > 18-Oct-2004 19:16:59.844 panic: critical: getifaddrs: Operation not supported > > And there remains a 'core' file in the system, > but named process exists and naming service is als...

Web resources about - Re: "Empty zones" and BIND 9.4 #4 - comp.protocols.dns.bind

Resources last updated: 2/20/2016 4:16:09 AM