king about.
Thanks,
.Ben Bridges.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
When you say “ISC packages”, are you referring to the packages in the
ppa:isc/bind repository on launchpad?
Ben Bridges
From: Ondřej Surý
Sent: Thursday, December 8, 2022 12:26 AM
To: Ben Bridges
Cc: Emmanuel Fusté ; bind-users@lists.isc.org
Subject: Re: Bind 9.16.1 crash
In fact, it’s as
It looks like that issue was occurring in a different part of the netmgr code
and was fixed 8 months ago.
Thanks,
Ben Bridges
From: bind-users On Behalf Of Andrew Latham
Sent: Wednesday, December 7, 2022 2:35 PM
Cc: bind-users@lists.isc.org
Subject: Re: Bind 9.16.1 crash
I see
https
From: Emmanuel Fusté
Sent: Wednesday, December 7, 2022 4:22 PM
To: Ben Bridges ; bind-users@lists.isc.org
Subject: Re: Bind 9.16.1 crash
Current ESV : 9.16.35
No, your release is not patched.
Add the ISC PPA repo and install the latest ESV. ISC PPA packaged are packaged
by the same maintainers
Ubuntu 20.04.5 is LTS and BIND 9.16 is the current stable ESV release, so
they’re both still fully supported (and fully patched).
Thanks,
Ben Bridges
From: bind-users On Behalf Of John Thurston
Sent: Wednesday, December 7, 2022 2:32 PM
To: bind-users@lists.isc.org
Subject: Re: Bind 9.16.1
uch appreciated. If this is not the proper forum for this posting, please
point me in the right direction.
Thanks,
Ben Bridges
[City Utilities]
[SpringNet]<http://www.springnet.net>
Sales 417.575.7000 | Support 417.874.8000 |
springnet.net<http://www.springnet.net>
--
Visit
an NS record which returns either "localhost" (preferably) or the
BIND server itself.)
Thanks,
Ben Bridges
[City Utilities]
[SpringNet]<http://www.springnet.net>
Sales 417.575.7000 | Support 417.874.8000 |
springnet.net<http://www.springnet.net>
___
: Configuring different TTLs in multiple RRs for the same domain
name, TYPE, and CLASS
On 24/03/2016 16:18, Ben Bridges wrote:
> TXT records are multiple-purpose. They can be used for SPF records,
> Office 365 "MS" records, DMARC records, or whatever arbitrary uses
> someone dreams u
;
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ben Bridges
Sent: Thursday, March 24, 2016 10:48 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Configuring different TTLs in multiple RRs for the same domain name,
TYPE, and CLASS
Greetings.
Is it possible in BIN
for all five records to 300 (or more
specifically, the TTL of the first one of the RRs in the file). I looked for a
BIND directive in the manual to change this behavior but could find no obvious
candidate.
Thanks,
Ben Bridges
Springfield, MO
___
P
It appears that dns1.zmi.at is refusing queries for
48-28.164.69.212.in-addr.arpa:
# dig @dns1.zmi.at 48-28.164.69.212.in-addr.arpa NS +norecurs
; <<>> DiG 9.5.0-P1 <<>> @dns1.zmi.at 48-28.164.69.212.in-addr.arpa NS
+norecurs
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HE
Since the CIDR block you have been allocated containing 63.250.251.0/24
is smaller than a /16, ARIN is delegating authority for the IN-ADDR.ARPA
zones for each of your /24's directly to your dns servers. In order for
your customer's dns servers to be authoritative for
251.250.63.IN-ADDR.ARPA, you'
Try
82.80-28.115.25.70.in-addr.arpa.IN PTR
mail.bgrinformatique.com.
instead of
82.115.25.70.in-addr.arpa. IN PTR mail.bgrinformatique.com.
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Beha
With the "file" statement in the zone declaration for that zone.
Zone "0/27.146.68.12.in-addr.arpa" {
...
file "blah-blah";
# orfile "0.27.146.68.12.in-addr.arpa"; as I believe Mark Andrews suggested
...
};
(See also Jeff Lightner's example earlier in this thread.)
I wasn't thinking straight. Ignore that. My apologies.
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ben Bridges
> Sent: Thursday, May 07, 2009 2:42 PM
> To: Mike Bernhardt
> Cc: b
27.10.in-addr.arpa. Try changing your
$GENERATE directives to
$GENERATE 0-127 $.10.in-addr.arpa. NS dhcp-01.adm.bart.gov.
$GENERATE 0-127 $.10.in-addr.arpa. NS mrep-02.adm.bart.gov.
and see if that works.
Ben Bridges
> -Original Message-
> From: bind
a best practice of implementation, how about security issues
?,
If I want to introduce one more server for caching functionality
alone how will I separate both in two different servers what are the
changes I will be making in my abc.com server and what configuration
should be there for the
d authoritative Name server or
a caching name server I was intend to set up a authoritative name
server, and hope by enabling recursion iam still authoritative server.
Regards
Mani
____
From: Ben Bridges [mailto:bbrid...@springnet.net]
You have recursion disabled on your abc.com server, and I believe that
is preventing your query from succeeding. My understanding is that the
contents of the root hints file are not stored in the server's cache
(which means, I think, that they are not themselves returned in response
to queries for
It sounds like you are looking for some configuration shorthand for BIND that
will allow you to configure it to be authoritative for the 16 /24's comprising
the /20 without having to explicitly configure 16 zones on BIND. I think
you're out of luck - BIND needs to have a zone statement for each
I agree, it's arbitrary. If you are wanting to format the name of your zone
similarly to the RFC, I believe the format would be
96/27.51.212.195.in-addr.arpa (for the subnet 195.212.51.96/27).
From: bind-users-boun...@lists.isc.org on behalf of Alan Clegg
Sen
eed to forward all queries for names outside of the AD zones?
>
>
>
> - Kevin
>
>
> Ben Bridges wrote:
> > > If I dump the delegation and make an MX record in the master, mail
> > will be
> > > OK, but t
You can use one $GENERATE statement in each zone to generate all 256
CNAME records for that zone.
Ben
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jeff Lasman
> Sent: Friday, March 13, 2009 3:31 PM
> To: Mark Andr
What is not working? Are you not getting the CNAME record for email.test.com?
Are you not getting the A record for email.tzqian.com? Are both zones on the
same dns server, or is each zone on a separate server? Which server are you
querying, and from what device are you issuing the query?
> If I dump the delegation and make an MX record in the master, mail will be
> OK, but then no one can query records in that zone because it's not
> actually delegated unless they point at MS-DNS.
Is there a reason why you can't point all of your internal hosts (AD and
non-AD) at your AD's for re
The first query for 130.168.193.66.in-addr.arpa/PTR/IN (with recursion
disabled) failed because your server is not authoritative for that
record and, since you have recursion disabled, it will not query the
authoritative server for it.
The second query for 130.168.193.66.in-addr.arpa/PTR/IN succee
Something like the following might work.
BIND:
...
channel my_syslog {
syslog local6;
severity info;
};
...
syslog.conf:
...
local6.* @remote-syslog-server // Forward all messages
with local6 facility t
Since you're not getting any response from your server (I'm assumimg
dns.tp.edu.tw is your server), you might want to check and make sure there are
no firewalls or ACL's blocking dns requests to your name servers.
From: bind-users-boun...@lists.isc.or
> sun
>NB: it also forwards to "isp" dns server.
If your sun server is configured to use your isp dns server as a forwarder,
then I think it will forward requests for example.test to the isp server even
though it delegated example.test to plesk. That would seem to be supported by
the fact
s.isc.org] On Behalf Of Ben Bridges
> Sent: Monday, February 02, 2009 1:29 PM
> To: S. Jeff Cold
> Cc: bind-users@lists.isc.org
> Subject: RE: BIND still will not resolve
>
> It also appears that your name server (iceman) is configured to accept
> IPv4 queries only from itself.
&g
It also appears that your name server (iceman) is configured to accept
IPv4 queries only from itself.
>#listen-on port 53 { 127.0.0.1; };
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Matthew Pounsett
>
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
f so, then iceman is misconfigured. Iceman
should be authoritative for jatec.us. The PTR record for 205.171.3.65
says it is resolver1.qwest.net. What is the output of "dig @127.0.0.1
jatec.us"?
Ben Bridges
> -Original Message-
> From: bind-users-boun...@lists.isc.org
fact
doing some sort of wildcarding. Maybe they have some sort of special
arrangement with the domain registrars???
> -Original Message-
> From: Scott Haneda [mailto:talkli...@newgeo.com]
> Sent: Thursday, January 29, 2009 12:06 AM
> To: Mark Andrews
> Cc: Ben Bridge
What specifically are you intending to wildcard? "com."? "net."? "."?
If so, then you would be implicitly making your name servers
authoritative for domains for which your servers are not supposed to be
authoritative.
Ben Bridges
> -Original Mes
When Section 5.1 of RFC 5321 says "If a CNAME record is found, the
resulting name is processed as if it were the initial name", it is
referring to the situation where a query is sent for the MX record for
xyz.com, and instead of an MX record being returned for xyz.com, a CNAME
record is returned fo
ial meaning or further
processing is associated with it (hence implying that it is ok if that
domain-name is defined as a CNAME somewhere else in the domain space).
Is that not the case? Is there some other part of the DNS specification
that forbids it?
Ben Bridges
> --
> Matus UHLAR - fantom
Since you are digging @127.0.0.1, I can't tell for sure on which server you are
performing the dig. But based on the responses, I'd say you were performing
the dig on d62.test.net. d62 is authoritative for 168.192.in-addr.arpa but not
for 0/16.168.192.in-addr.arpa. (The NS record for 0/16.168
I've always assumed that the ";..." line in the example zone file right
after the SOA record and the (...) in the SOA record itself meant that
such information about the parent zone 2.0.192.in-addr.arpa had been
intentionally left out for the sake of brevity and clarity.
Ben Br
39 matches
Mail list logo
