Re: [Off-Topic] RE: This list's prefix
Not everyone has the same software infrastructure, and not everyone has the same visual proficiency. For this reason a Subject Prefix helps on manage much messages on inbox. I don't understand why the Subject Prefix can be inconvenient for someone, if it's brief. Al 06/06/13 01:11, En/na Stuart Browne ha escrit: -Original Message- From: bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org [mailto:bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org] On Behalf Of Elmar K. Bins Sent: Thursday, 6 June 2013 5:46 AM To: bind-users@lists.isc.org Subject: Re: This list's prefix war...@kumari.net (Warren Kumari) wrote: And the 100-dollar-question is: How do you remove them on outgoing mails? ;-) You don't -- that's part of the churches evangelism / outreach effort. ;) (Less flip answer: sorry, don't know if you can...) Just wondering, because your responses arrive without them. If you run your own SMTP gateway that supports milters, have-at-it. Not overly difficult, plenty of C and perl examples out there. Stuart ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RFC 1918 Warning Event ID 2
Dears,
I was receiving the below warning event :
Event Type:Warning
Event Source:named
Event Category:None
Event ID:2
Date:6/5/2013
Time:11:01:30 AM
User:N/A
Computer:DNS01
Description:
client 10.0.11.162#62089: RFC 1918 response from Internet for
26.201.21.172.in-addr.arpa
And after searching I found a solution which says :
** create empty zones as following
zone 10.IN-ADDR.ARPA {
type master;
file empty;
};
zone 16.172.IN-ADDR.ARPA {
type master;
file empty;
};
...
zone 31.172.IN-ADDR.ARPA {
type master;
file empty;
};
zone 168.192.IN-ADDR.ARPA {
type master;
file empty;
};
** And empty zone is
$TTL86400
@ IN SOA ns1.eccsolutions.net. hostmaster.eccsolutions.net. (
2013050901 ; Serial
28800 ; Refresh
14400 ; Retry
360; Expire
86400 ); Minimum
IN NS ns1.eccsolutions.net.
IN NS ns2.eccsolutions.net.
Now I receive such events in my Secondary DNS server
Event Type:Warning
Event Source:named
Event Category:None
Event ID:2
Date:6/3/2013
Time:4:05:54 PM
User:N/A
Computer:DNS02
Description:
zone 10.IN-ADDR.ARPA/IN: saved 'db.empty' as 'db-2072'
And
Event Type:Error
Event Source:named
Event Category:None
Event ID:1
Date:6/4/2013
Time:11:59:44 AM
User:N/A
Computer:DNS02
Description:
zone 10.IN-ADDR.ARPA/IN: loading from master file db.empty failed: not at top
of zone
what is wrong with my configuration and how to solve this ?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: RFC 1918 Warning Event ID 2
In message dub101-ds17938d7e8867dfe699b6edc2...@phx.gbl, Eng_M.wahab writes
:
Dears,
I was receiving the below warning event :
Event Type:Warning
Event Source:named
Event Category:None
Event ID:2
Date:6/5/2013
Time:11:01:30 AM
User:N/A
Computer:DNS01
Description:
client 10.0.11.162#62089: RFC 1918 response from Internet for
26.201.21.172.in-addr.arpa
And after searching I found a solution which says :
** create empty zones as following
zone 10.IN-ADDR.ARPA {
type master;
file empty;
};
zone 16.172.IN-ADDR.ARPA {
type master;
file empty;
};
...
zone 31.172.IN-ADDR.ARPA {
type master;
file empty;
};
zone 168.192.IN-ADDR.ARPA {
type master;
file empty;
};
** And empty zone is
$TTL86400
@ IN SOA ns1.eccsolutions.net.
hostmaster.eccsolutions.net. (
2013050901 ; Serial
28800 ; Refresh
14400 ; Retry
360; Expire
86400 ); Minimum
IN NS ns1.eccsolutions.net.
IN NS ns2.eccsolutions.net.
Now I receive such events in my Secondary DNS server
Event Type:Warning
Event Source:named
Event Category:None
Event ID:2
Date:6/3/2013
Time:4:05:54 PM
User:N/A
Computer:DNS02
Description:
zone 10.IN-ADDR.ARPA/IN: saved 'db.empty' as 'db-2072'
And
Event Type:Error
Event Source:named
Event Category:None
Event ID:1
Date:6/4/2013
Time:11:59:44 AM
User:N/A
Computer:DNS02
Description:
zone 10.IN-ADDR.ARPA/IN: loading from master file db.empty failed: not at
top of zone
what is wrong with my configuration and how to solve this ?
Follow the instructions on the second server. i.e. use master zones
not slave zones. Slave zones cannot share files.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Doug Barton do...@dougbarton.us wrote: On 06/05/2013 11:33 AM, Tony Finch wrote: I believe the ANY hack on mail servers was a Sendmailism 20ish years ago. s/Send/q/ No, I meant Sendmail - see http://fanf.livejournal.com/10.html Sendmail at one time tried to use ANY for combined MX+A lookups, which doesn't work. qmail uses ANY for CNAME lookups, which sort-of works, apart from a number of bugs described on the page above. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Vernon Schryver v...@rhyolite.com wrote: [ANY query for combined MX/A lookup was] a bad hack then and it has remained a bad hack :-) I would not agree if you could rely on the open resolvers continuing to do what they're doing, if you didn't care about parsing 3 or 4 KBytes of irrelevant bits to get the RRsets you want, and if you don't care about spending 9 or 10 IP packets on a truncated UDP responce and then a full TCP response instead of 6 on 3 separate queries. With BIND as your DNS server, it could be a win for bursts of mail to a single SMTP server if your SMTP client is too dumb to do the obvious, safe caching. At worst you would need to ask for ANY, MX, A, and , but some of the time the ANY would have all of the RRsets. There are other caveats: The ANY query does not trigger additional section processing, so if you find MX records in the result you have to make follow-up queries to get the A and records of the targets; if you made an MX query in the first place you often don't need to make more queries. The ANY query does not trigger alias processing, so if there is a CNAME chain you have to follow it yourself. This is a waste because if you made an MX query in the first place the server would have given you the whole chain without further queries. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RFC 1918 Warning Event ID 2
Thanks Mark,
It works in a perfect way ;)
As for the below error, does it have anything to do with the RFC 1918 issue
or it's another issue ?
Event Type:Error
Event Source:named
Event Category:None
Event ID:1
Date:6/6/2013
Time:12:09:44 PM
User:N/A
Computer:DNS01
Description:
client 81.xx.xx.xx#63209: update '0.10.in-addr.arpa/IN' denied
-Original Message-
From: Mark Andrews
Sent: Thursday, June 06, 2013 10:17 AM
To: Eng_M.wahab
Cc: bind-us...@isc.org
Subject: Re: RFC 1918 Warning Event ID 2
In message dub101-ds17938d7e8867dfe699b6edc2...@phx.gbl, Eng_M.wahab
writes
:
Dears,
I was receiving the below warning event :
Event Type:Warning
Event Source:named
Event Category:None
Event ID:2
Date:6/5/2013
Time:11:01:30 AM
User:N/A
Computer:DNS01
Description:
client 10.0.11.162#62089: RFC 1918 response from Internet for
26.201.21.172.in-addr.arpa
And after searching I found a solution which says :
** create empty zones as following
zone 10.IN-ADDR.ARPA {
type master;
file empty;
};
zone 16.172.IN-ADDR.ARPA {
type master;
file empty;
};
...
zone 31.172.IN-ADDR.ARPA {
type master;
file empty;
};
zone 168.192.IN-ADDR.ARPA {
type master;
file empty;
};
** And empty zone is
$TTL86400
@ IN SOA ns1.eccsolutions.net.
hostmaster.eccsolutions.net. (
2013050901 ; Serial
28800 ; Refresh
14400 ; Retry
360; Expire
86400 ); Minimum
IN NS ns1.eccsolutions.net.
IN NS ns2.eccsolutions.net.
Now I receive such events in my Secondary DNS server
Event Type:Warning
Event Source:named
Event Category:None
Event ID:2
Date:6/3/2013
Time:4:05:54 PM
User:N/A
Computer:DNS02
Description:
zone 10.IN-ADDR.ARPA/IN: saved 'db.empty' as 'db-2072'
And
Event Type:Error
Event Source:named
Event Category:None
Event ID:1
Date:6/4/2013
Time:11:59:44 AM
User:N/A
Computer:DNS02
Description:
zone 10.IN-ADDR.ARPA/IN: loading from master file db.empty failed: not at
top of zone
what is wrong with my configuration and how to solve this ?
Follow the instructions on the second server. i.e. use master zones
not slave zones. Slave zones cannot share files.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Bind 9.9.3 configuration message: missing 'file' entry
The brackets were wrong and we should have checked that obj was true. The patch you provided makes the log message go away. The bind9 service appears to be working normally, and named-checkconf produces no output. Thanks. Jeff. FYI. The patch for /lib/bind9/check.c provided earlier in this thread appears to be applicable to 9.9.3-P1 as well. There were no changes to this file between the two releases. Jeff. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RFC 1918 Warning Event ID 2
In message dub101-ds177bb02f419f2957ff9507c2...@phx.gbl, Eng_M.wahab writes : Thanks Mark, It works in a perfect way ;) As for the below error, does it have anything to do with the RFC 1918 issue or it's another issue ? Event Type:Error Event Source:named Event Category:None Event ID:1 Date:6/6/2013 Time:12:09:44 PM User:N/A Computer:DNS01 Description: client 81.xx.xx.xx#63209: update '0.10.in-addr.arpa/IN' denied You have clients attempting to dynamically update the reverse zone. This could be a dhcp server or machines the machines themselves. You need to decide if this is appropriate or not and if appropriate adjust the configuration to allow it. By default updates are denied. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RFC 1918 Warning Event ID 2
Thnkx one more time Mark , It's wrong behavior so I keep the default settings. -Original Message- From: Mark Andrews Sent: Thursday, June 06, 2013 2:27 PM To: Eng_M.wahab Cc: bind-us...@isc.org Subject: Re: RFC 1918 Warning Event ID 2 In message dub101-ds177bb02f419f2957ff9507c2...@phx.gbl, Eng_M.wahab writes : Thanks Mark, It works in a perfect way ;) As for the below error, does it have anything to do with the RFC 1918 issue or it's another issue ? Event Type:Error Event Source:named Event Category:None Event ID:1 Date:6/6/2013 Time:12:09:44 PM User:N/A Computer:DNS01 Description: client 81.xx.xx.xx#63209: update '0.10.in-addr.arpa/IN' denied You have clients attempting to dynamically update the reverse zone. This could be a dhcp server or machines the machines themselves. You need to decide if this is appropriate or not and if appropriate adjust the configuration to allow it. By default updates are denied. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: This list's prefix
-Original Message- From: Elmar K. Bins e...@4ever.de Organization: unorganized since 1789 Date: Thursday, June 6, 2013 6:18 AM To: bind-users@lists.isc.org bind-users@lists.isc.org Subject: Re: This list's prefix s...@resistor.net (SM) wrote: And the 100-dollar-question is: How do you remove them on outgoing mails? ;-) The answer is to edit the subject line after hitting the reply button. :-) I feared this would be the ugly truth... Or don't buy into religion and have a simpler life. ;-) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [Architecture discussion] IPv6 and best practices for DNS naming and the MX/SMTP problem
Hello Carsten and Kevin Thanks for your answers. As a short summary, I will use (and recommend) the following ways: - consider .local/.loc/.intra/.lan etc. as legacy which should be eliminated (Microsoft officially supports Active Directory domain renaming procedures for that). - preferred way is to use intra.example.com, dmz.example.com etc. so example.com itself can stay fully public while the sub DNS zones can be setup restricted but the correct DNS delegation chains must be complete so every DNS resolver on the world on a authorized system (this can also be a friend company or local office over VPN, not only the LAN behind the firewall itself) can resolve the names and IP(v6) adresses successfully in both directions. - In BIND this list of authorized resolvers can be setup with the allow-query directive, so unauthorized systems don't get a DNS timeout, they just get a refused answer when trying to resolve internal resources. - a smart relay host with both public IPv4 and IPv6 addresses on the network interfaces eliminates the dual stack MX / EHLO hostname IPv4-NAT problem because I fully can control the way between my internal mail server and the smart relay host (they always can [and should] communicate over IPv6 for example so there is no need to point the MX record to the firewall instead internal mail server itself because of NAT) = this even allows me to put the smart relay host as a friend system for my internal DNS server so the MTA on the smart relay host knows mailserv.intra.example.com as valid EHLO hostname and can send i...@example.com to infou...@mailserv.intra.example.com for example (forwarding rule). In my own network I already started to implement several of these measures. My current goal is to implement dual-stack for every component/network segment so I can give some feedback in a later time. When everything works well, another goal is to implement that in my customer's networks (I am working as freelancer for several regional customers) as part of future IT migration projects. Corrections and additions are welcome. :-) Andreas - Original Message - From: Carsten Strotmann c...@strotmann.de To: Andreas Meile mailingli...@andreas-meile.ch Cc: bind-users@lists.isc.org Sent: Monday, May 27, 2013 8:20 AM Subject: Re: [Architecture discussion] IPv6 and best practices for DNS naming and the MX/SMTP problem Hello Andreas, [...] -- Teste die PC-Sicherheit mit www.sec-check.net ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
In article mailman.488.1370508226.20661.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: The ANY query does not trigger alias processing, so if there is a CNAME chain you have to follow it yourself. This is a waste because if you made an MX query in the first place the server would have given you the whole chain without further queries. Unless the links in the CNAME chain are in the same bailiwick, isn't the client going to ignore them and follow them itself, to avoid cache poisoning? -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Barry Margolin bar...@alum.mit.edu wrote: In article mailman.488.1370508226.20661.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: The ANY query does not trigger alias processing, so if there is a CNAME chain you have to follow it yourself. This is a waste because if you made an MX query in the first place the server would have given you the whole chain without further queries. Unless the links in the CNAME chain are in the same bailiwick, isn't the client going to ignore them and follow them itself, to avoid cache poisoning? The client is a stub resolver, the server is a recursive resolver. The recursive server will either serve the CNAME chain from cache or chase it safely if necessary, Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Build BIND 9.9.3-P1 on Solaris 10 with 'cc', using OpenSSL built with 'gcc'?
Is there any way to build BIND 9.9.3-P1 on Solaris 10 with 'cc', using OpenSSL built with 'gcc'? There are many other packages that use OpenSSL that only build with 'gcc', but BIND 9.9.3-P1 won't compile on Solaris 10 with 'gcc' (I think it did previously, as my notes have 'CC=gcc' set in the 'configure' statement, but the 'README' says building with gcc is not supported unless gcc is the vendor's usual compiler). Building with 'gcc' fails when trying to test whether 'openssl' works, and has other complaints before that. It appears to build with 'cc' if OpenSSL is disabled, which disables DNSSEC (OK for now as we don't use it, yet). Thanks, Mike -- Mike PetersonInformation Security Analyst - Audit E-mail: mi...@noc.utoronto.caWWW: http://www.noc.utoronto.ca/ Tel: 416-978-5230 Fax: 416-978-6620 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
From: Tony Finch d...@dotat.at Sendmail at one time tried to use ANY for combined MX+A lookups, which doesn't work. That would be true and relevant if sendmail did that. Requesting ANY, not getting all of the MX, A, and/or records needed, and failing to continue making other DNS requests simply does not work. If sendmail did that, then given what BIND has done for eons, that bug would have been noticed immediately eons ago. Tony Finch pointed out privately that it wasn't until sendmail 8.12 that stopped asking for ANY records. I found 8.11.6 on http://rpm.pbone.net/index.php3/stat/26/dist/4/size/1399432/name/sendmail-8.11.6-1.62.3.src.rpm sendmail/domain.c in 8.11.6 started by requesting ANY. However it continued requesting , A, and/or MX and parsing ANSWER sections until it got the records needed. It did not stop with the ANY response unless the ANY response was dispositive (e.g contained all types or NXDOMAIN). My superficial code reading says it ignored ADDITIONAL sections and so ignored potentially interesting A or RRs in ADDITIONAL sections. My quick side-by-side comparison of the old 8.11.6 and current 8.14.7 domain.c says that the relevant difference is that 8.14.7 starts with A or and never tries ANY. However, that is about dns_getcanonname(). getmxrr() in both 8.11.6 and 8.14 starts and ends with MX and never messes with ANY. There is broken in that ANY scheme. It might or might not reduce average DNS traffic for sending mail. I'd vote against it today for various reasons, but that doesn't make it wrong. There is an interesting comment in the 8.11.6 version of domain.c: ** The ANY query is really meant to prime ** the cache so this isn't dangerous. If your SMTP client is very close to your recursive resolvers (typical 10 or 20 years ago), then making an ANY request that you ignore could reduce your external DNS traffic by priming (not refreshing) the resolver's cache. I don't know that getmxrr() in sendmail is not called before dns_getcanonname(), which would prevent cache the priming by an ANY request. About chasing CNAMEs safely or otherwise, please recall the somewhat controversial DontExpandCnames. The current cf/README says: confDONT_EXPAND_CNAMES DontExpandCnames [False] If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this. For example, if FTP.Foo.ORG is a CNAME for Cruft.Foo.ORG, then with this option set a lookup of FTP will return FTP.Foo.ORG; if clear it returns Cruft.FOO.ORG. N.B. you may not see any effect until your downstream neighbors stop doing CNAME lookups as well. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
Vernon Schryver v...@rhyolite.com wrote: About chasing CNAMEs safely or otherwise, please recall the somewhat controversial DontExpandCnames. The current cf/README says: confDONT_EXPAND_CNAMES DontExpandCnames [False] If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this. For example, if FTP.Foo.ORG is a CNAME for Cruft.Foo.ORG, then with this option set a lookup of FTP will return FTP.Foo.ORG; if clear it returns Cruft.FOO.ORG. N.B. you may not see any effect until your downstream neighbors stop doing CNAME lookups as well. That sounds like it was written about 15 years ago when the DRUMS working group was active. This currently violates the published standards refers to RFC 1123, and the mail-related parts of that were obsoleted by RFC 2821 and then RFC 5321 which allow non-canonical domains (and in fact did right from the first draft of November 1995). Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Build BIND 9.9.3-P1 on Solaris 10 with 'cc', using OpenSSL built with 'gcc'?
Supported in this case means accept bug reports for not we know it won't work. Mark In message 51b0ba26.9030...@noc.utoronto.ca, Mike Peterson writes: Is there any way to build BIND 9.9.3-P1 on Solaris 10 with 'cc', using OpenSSL built with 'gcc'? There are many other packages that use OpenSSL that only build with 'gcc', but BIND 9.9.3-P1 won't compile on Solaris 10 with 'gcc' (I think it did previously, as my notes have 'CC=gcc' set in the 'configure' statement, but the 'README' says building with gcc is not supported unless gcc is the vendor's usual compiler). Building with 'gcc' fails when trying to test whether 'openssl' works, and has other complaints before that. It appears to build with 'cc' if OpenSSL is disabled, which disables DNSSEC (OK for now as we don't use it, yet). Thanks, Mike -- Mike PetersonInformation Security Analyst - Audit E-mail: mi...@noc.utoronto.caWWW: http://www.noc.utoronto.ca/ Tel: 416-978-5230 Fax: 416-978-6620 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
