Re: DNSSEC with 9.7.2-P2
On 12/11/10 12:49, David Forrest wrote:
and, on checking named.conf, I found the entry for br. as:
trusted-keys {
br. 257 3 5
AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=;
};
This key is invalid for br.
Since you're running 9.7.2, don't do this. br is signed by the root;
instead, defined a managed-keys statement for . and let the root
DNSSEC take care of it.
See:
http://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
On 29.10.10 12:49, Mark Andrews wrote: And they can do a SMTP level rejection rather than waiting for the sending server to abandon sending the email due to multiple timeouts. Just return 550 for all mail directed to users at those hosts. It would be nice if we could standardise a MX target of . as saying that this domain doesn't accept email e.g. MX 0 . the same way as SRV 0 0 0 . means that there is no service for the named protocol. That way the sending MTA or the MSA can reject the email. Every time it get suggested people shoot it down worrying about private nets that have addresses at . or get worried about thousands of machines making A/ queries for . where the MTA doesn't check that the MX target is a valid host name. the same would apply for any other hostname not recognized by mailservers. Even localhost, if some servers do not contain zone for it. Technically the best solution would be dropping fallback for A address, however it's apparently unapplicable (or would take years). BTW. I was told that . is not a valid hostname and that it causes DNSSEC problems, at least with debian's named (9.6 ESV now, 9.5.1 before) ... can you confirm this? -- 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. Support bacteria - they're the only culture some people have. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
In message 20101112135657.gb22...@fantomas.sk, Matus UHLAR - fantomas writes: On 29.10.10 12:49, Mark Andrews wrote: And they can do a SMTP level rejection rather than waiting for the sending server to abandon sending the email due to multiple timeouts. Just return 550 for all mail directed to users at those hosts. It would be nice if we could standardise a MX target of . as saying that this domain doesn't accept email e.g. MX 0 . the same way as SRV 0 0 0 . means that there is no service for the named protocol. That way the sending MTA or the MSA can reject the email. Every time it get suggested people shoot it down worrying about private nets that have addresses at . or get worried about thousands of machines making A/ queries for . where the MTA doesn't check that the MX target is a valid host name. the same would apply for any other hostname not recognized by mailservers. Even localhost, if some servers do not contain zone for it. Technically the best solution would be dropping fallback for A address, however it's apparently unapplicable (or would take years). BTW. I was told that . is not a valid hostname and that it causes DNSSEC problems, at least with debian's named (9.6 ESV now, 9.5.1 before) ... can you confirm this? . isn't a valid hostname but named will accept it as a place holder. % named-checkzone example test test:1: no TTL specified; using SOA MINTTL instead zone example/IN: example/MX '.' (out of zone) has no addresses records (A or ) zone example/IN: loaded serial 0 OK % cat test @ IN SOA . . 0 0 0 0 0 @ IN NS . @ IN MX 10 . % It's easy enough to remove the address checks for .. DNSSEC doesn't care about valid hostnames. -- 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. Support bacteria - they're the only culture some people have. ___ 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: out of place mx records.
In message 20101112135657.gb22...@fantomas.sk, Matus UHLAR - fantomas writes: On 29.10.10 12:49, Mark Andrews wrote: And they can do a SMTP level rejection rather than waiting for the sending server to abandon sending the email due to multiple timeouts. Just return 550 for all mail directed to users at those hosts. It would be nice if we could standardise a MX target of . as saying that this domain doesn't accept email e.g. MX 0 . the same way as SRV 0 0 0 . means that there is no service for the named protocol. That way the sending MTA or the MSA can reject the email. Every time it get suggested people shoot it down worrying about private nets that have addresses at . or get worried about thousands of machines making A/ queries for . where the MTA doesn't check that the MX target is a valid host name. the same would apply for any other hostname not recognized by mailservers. Even localhost, if some servers do not contain zone for it. Technically the best solution would be dropping fallback for A address, however it's apparently unapplicable (or would take years). BTW. I was told that . is not a valid hostname and that it causes DNSSEC problems, at least with debian's named (9.6 ESV now, 9.5.1 before) ... can you confirm this? On 13.11.10 01:24, Mark Andrews wrote: . isn't a valid hostname but named will accept it as a place holder. % named-checkzone example test test:1: no TTL specified; using SOA MINTTL instead zone example/IN: example/MX '.' (out of zone) has no addresses records (A or ) zone example/IN: loaded serial 0 OK % cat test @ IN SOA . . 0 0 0 0 0 @ IN NS . @ IN MX 10 . % It's easy enough to remove the address checks for .. what about check-mx setting, can it be also affected by this setting? DNSSEC doesn't care about valid hostnames. ok -- 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. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC with 9.7.2-P2
On 11/12/2010 7:49 AM, David Forrest wrote:
While running BIND 9.7.2-P2 built with defaults on F11
[..]
and, on checking named.conf, I found the entry for br. as:
trusted-keys {
br. 257 3 5
AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=;
};
If Fedora 11 (I'm assuming that is what F11 is) has built in
trust-anchors in the distributed named.conf, someone needs to talk to
them...
As already noted, the root is signed, inserting individual keys into the
named.conf for TLDs that are signed and have DS records in the root is a
really, REALLY bad idea.
Doing a search for relevant keywords proves that yes, Fedora 11 ships
with a broken configuration and the recommendation (from those that seem
to know no better) is ooh, DNSSEC BAD, turn it off.
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: Debugging configuring TKEY: failure (w/samba4)
I recently went through this and have it working. Look through the archives for
'GSS-TSIG and Active Directory'.
https://lists.isc.org/mailman/mmsearch/bind-users?config=bind-users.htsearchrestrict=exclude=method=andformat=shortsort=scorewords=GSS-TSIG+and+Active+Directory
Things to check:
1) You are running the newest version of Bind.
2) You might try compiling Bind with --with-gssap=/usr
3) Double check your krb5.conf and make sure you have arcfour-hmac-md5 listed
first in default_tgs_enctypes and default_tkt_enctypes.
4) When you create your keytab don't define crypto it will default to
RC4-HMAC-NT. (ktpass -out foo.keytab -princ DNS/foo.example.org at EXAMPLE.ORG
-pass * -mapuser foo at example.org)
5) FWIW, I am not using any of the Samba settings. The DNS server isn't joined
to the AD it just has the krb5.conf setup and a keytab for DNS/dnserver.domain.
_
Nicholas Miller, ITS, University of Colorado at Boulder
On Nov 10, 2010, at 6:48 AM, Adam Tauno Williams wrote:
I'm attempting to get Bind 9.7.2 (built on openSUSE 11.3) running in
relation to Samba4; this uses GSSAPI authentication to update the Bind
zones. Everything works except this part. I've build bind with
--with-gssapi, verified krb5 is linked in, and verified [at least with
kinit and other trivial krb5 tools] that Kerberos/GSSAPI is working.
But when I add:
options {
tkey-gssapi-credential DNS/ad.mormail.com;
tkey-domain AD.MORMAIL.COM;
...
}
- to my bind configuration bind fails to start with -
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone: D.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
8.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
9.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
A.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
B.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
8.B.D.0.1.0.0.2.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: configuring TKEY: failure
Nov 10 08:43:32 opensuse named[3021]: loading configuration: failure
Nov 10 08:43:32 opensuse named[3021]: exiting (due to fatal error)
I've tried playing with log levels, etc... and I just can seem to dig
any more information out of it. Are there any procedures / tips for
debugging a configuring TKEY: failure message?
--
Adam Tauno Williams awill...@whitemice.org
___
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: DNSSEC with 9.7.2-P2
On Fri, 12 Nov 2010, Alan Clegg wrote:
On 11/12/2010 7:49 AM, David Forrest wrote:
While running BIND 9.7.2-P2 built with defaults on F11
[..]
and, on checking named.conf, I found the entry for br. as:
trusted-keys {
br. 257 3 5
AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=;
};
If Fedora 11 (I'm assuming that is what F11 is) has built in
trust-anchors in the distributed named.conf, someone needs to talk to
them...
It was a separate file named.keys, and if the machine has received all the
updates it should no longer be included in named.conf. Keys were never
hardcoded in named.conf. If that's where these keys are, someone put them
in their manually.
Paul
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC with 9.7.2-P2
On 12/11/10 14:51, Alan Clegg wrote:
On 11/12/2010 7:49 AM, David Forrest wrote:
While running BIND 9.7.2-P2 built with defaults on F11
[..]
and, on checking named.conf, I found the entry for br. as:
trusted-keys {
br. 257 3 5
AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=;
};
If Fedora 11 (I'm assuming that is what F11 is) has built in
trust-anchors in the distributed named.conf, someone needs to talk to
them...
They have, by bundling a copy of dnssec-conf. In addition, there is no
system scheduled cron job to update these IIRC - the expectation was
that RPM updates would do the job - and sadly F11 is now off support,
which is a bit of a hole in the reasoning :o(
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: DNSSEC with 9.7.2-P2
Not a hole if you look at the reasoning for Fedora itself. It has a
short lifecycle and they expressly tell folks not to use it for
Production due to this. It is meant to be bleeding edge for testing the
latest/greatest. It is used as a test bed for what makes it into RHEL.
For Production (RPM based system) you should use RHEL or CentOS which
has a much longer life cycle. (Speaking of which, RHEL6 was just put in
general release this week.) Of course the downside to this is that they
often don't have the latest BIND packages built but they do backport
security fixes from later BIND packages into the earlier one and do add
some features from the later ones into the earlier one.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Phil Mayers
Sent: Friday, November 12, 2010 10:33 AM
To: bind-users@lists.isc.org
Subject: Re: DNSSEC with 9.7.2-P2
On 12/11/10 14:51, Alan Clegg wrote:
On 11/12/2010 7:49 AM, David Forrest wrote:
While running BIND 9.7.2-P2 built with defaults on F11
[..]
and, on checking named.conf, I found the entry for br. as:
trusted-keys {
br. 257 3 5
AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PMNpyw3XCFQWP/XsT
0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1NGbGfs513y6d
y1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNp
y6AM=;
};
If Fedora 11 (I'm assuming that is what F11 is) has built in
trust-anchors in the distributed named.conf, someone needs to talk to
them...
They have, by bundling a copy of dnssec-conf. In addition, there is no
system scheduled cron job to update these IIRC - the expectation was
that RPM updates would do the job - and sadly F11 is now off support,
which is a bit of a hole in the reasoning :o(
___
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
Re: DNSSEC with 9.7.2-P2
On 12/11/10 15:45, Lightner, Jeff wrote: For Production (RPM based system) you should use RHEL or CentOS which has a much longer life cycle. (Speaking of which, RHEL6 was just put in I don't agree with your line of reasoning. RHEL may have longer update cycles, but there's no guarantee a particular RHEL install will be applying updates in real-time, so the keys in the dnssec-conf package may still get out of date, or a RHEL install may run after it's 5-year update cycle ends. I think the dnssec-conf package should have had a nightly cron job to refresh these keys, and it was a mistake to deploy without such. Just my opinion of course. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named won't restart
It is possible. I found that named wasn't logging to the configured /var/log/named because logrotate failed to reload named after creating the new file. If rndc stop was timing out because the daemon was trying to write to the log file, then it could have been a catch 22 situation. I have since removed the logrotate configuration in favor of the native named rotation provided by the channel statement. We'll see if this hypothesis proves true. Thanks. cv On 11/12/10 4:00 AM, Bèrto ëd Sèra wrote: maybe this can be of help: http://bugs.gentoo.org/show_bug.cgi?id=324315 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dynamic updates via libbind.
I am currently using libbind to do dynamic updates in C. I have looked in the bind 9.7.x source and I don't see a replacement mechanism for this. Is there one or is there one planned in bind10? Thanks -- Jack. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
one remaining error message in named log startup messages
Am building a new nameserver, with vanilla CentOS 5.5, and am in the home stretch. I see one last anomalous message that says: adjusted limit on open files from 1024 to 1048576 The named service works just fine.I have about 260 zone files...or is this just adjusting the number of files for the parent process? Googled this: http://forums.gentoo.org/viewtopic-t-812664.html which says to add a line: named soft nofile 4096 to /etc/security/limits.conf Did that, then tried both restarting named and rebooting the machine, but it doesn't make a difference. named -v yields: BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 Comments, suggestions? -- One must think like a hero to behave like a merely decent human being. - May Sarton Having overcome your worst fear, the thing you are most vulnerable to, that is the definition of heroic. Also, it's such a worthwhile human activity. The most. -Fran Liebowitz Funny how it's women who speak so well of the real heroism, that of going on, of being true. Stewart Dean, Unix System Admin, Bard College, New York 12504 sd...@bard.edu voice: 845-758-7475, fax: 845-758-7035 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: why one shouldn't use relative hostnames
Thank you both and Kevin I for one would really appreciate if you would compose that web page and put it out there! On Nov 11, 2010, at 8:40 AM, Stacey Jonathan Marshall wrote: Additionally a wildcard record in one of the the searched domains would cause a false positive to be returned causing an outage to the service/services. And if your not in control of the zone or the search order it could be difficult to rectify. -Stacey On 11/11/2010 00:30, Kevin Darcy wrote: On 11/10/2010 1:19 PM, Maria Iano wrote: We are working with a software vendor whose software only works with relative hostnames - they say it can't cope with a fully- qualified domain name. They want us to make sure the necessary domain is in all clients' search lists. Does anyone have any good references for me to explanations of why this is a very bad thing. I would find quick access to thoughtful well-phrased arguments very useful right now. I've looked for such a thing from time to time, with no success. Maybe I need to compose something like that. Main reasons for not using shortnames: a) Security. The problem cited way back in RFC 1535 still exists, in a slightly different form, with respect to shortnames, i.e. they're ambiguous and can cause names to resolve unexpectedly, thus causing connections to be made to unexpected hosts, which might not be trusted. E.g. we have multiple DNS names with the first label of mailroom, one could potentially connect to the wrong mailroom server, depending on the (somewhat arbitrary) ordering of one's searchlist. A less-trusted mailroom server could trojan the more- trusted one. b) Capacity and performance (specifically, query latency). Each searchlist element magnifies query volume, and increases query latency for all queries which don't happen to resolve with the first element in the searchlist. Names which don't resolve at all (typos, obsolete references, etc.) exhaust the *entire* searchlist, which has maximum latency to the invoking application, and uses maximum nameservice-infrastructure, network, logging and/or server resources. c) Undesired dependencies and co-ordination challenges. Shortname resolution depends on the precise configuration of searchlists, but in many organizations the DNS infrastructure experts are not in the same department as those who control the configuration of searchlists (which are often client OS experts rather than in the server or networking areas), so there can be co-ordination challenges between the departments. When using FQDNs, searchlists are unnecessary and therefore the dependencies and co-ordination challenges are minimized d) Inconsistency between internal and Internet environments; future- proofing. Shortnames are, by and large, not used on the Internet, because of the foregoing reasons, writ large because of the sheer scale and diversity of the Internet and its DNS namespace. If shortnames are used on an internal network, there is an inconsistency between the the two environments, internal and Internet, which may cause confusion and interoperability challenges, should a particular function or subsystem be out- hosted and/or attached to an Internet-accessible cloud at some point in the future. Under this heading, it should be noted that some Internet-oriented technologies absolutely require FQDNs as part of their formal specification. To my knowledge, no formal specifications (other than WINS/NETBIOS perhaps) require shortnames. Therefore, to be most flexible and accommodating to changing technologies and environments, it is best to use the naming format -- FQDNs -- which is most likely to be compatible and interoperable going forward. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
how to see ALL NS records in a zone file with dig
If I use dig NS domain name I know I will see the NS records for the domain. I know I can do the same thing for other RR types. In the case where a zone file has RR records that define delegation for subdomains why can't I use this dig command to see those delegations? I assume this is easy and it's just something I've forgotten how to do. Thanks for any help you can provide! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to see ALL NS records in a zone file with dig
On Fri, 12 Nov 2010, M. Meadows wrote: If I use dig NS domain name I know I will see the NS records for the domain. I know I can do the same thing for other RR types. In the case where a zone file has RR records that define delegation for subdomains why can't I use this dig command to see those delegations? I assume this is easy and it's just something I've forgotten how to do. Thanks for any help you can provide! Try adding +norec to the dig command to disable recursion by the server: dig +norec -t ns name @server That will get the NS records as known by the parent above the delegation cut, instead of the NS records as known by the child below the delegation cut. Differences in those sets can sometimes be, shall we say, interesting. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
libbind error
I believe I found a bug in the libbind code. Is this the correct place to report that? Thanks -- jack ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: out of place mx records.
In message 20101112143542.ga23...@fantomas.sk, Matus UHLAR - fantomas writes:
In message 20101112135657.gb22...@fantomas.sk, Matus UHLAR - fantomas wri
tes:
On 29.10.10 12:49, Mark Andrews wrote:
And they can do a SMTP level rejection rather than waiting for the
sending server to abandon sending the email due to multiple timeouts.
Just return 550 for all mail directed to users at those hosts. It
would be nice if we could standardise a MX target of . as saying
that this domain doesn't accept email e.g. MX 0 . the same way
as SRV 0 0 0 . means that there is no service for the named
protocol. That way the sending MTA or the MSA can reject the email.
Every time it get suggested people shoot it down worrying about
private nets that have addresses at . or get worried about thousands
of machines making A/ queries for . where the MTA doesn't
check that the MX target is a valid host name.
the same would apply for any other hostname not recognized by mailservers
.
Even localhost, if some servers do not contain zone for it.
Technically the best solution would be dropping fallback for A address,
however it's apparently unapplicable (or would take years).
BTW.
I was told that . is not a valid hostname and that it causes DNSSEC
problems, at least with debian's named (9.6 ESV now, 9.5.1 before)
... can you confirm this?
On 13.11.10 01:24, Mark Andrews wrote:
. isn't a valid hostname but named will accept it as a place holder.
% named-checkzone example test
test:1: no TTL specified; using SOA MINTTL instead
zone example/IN: example/MX '.' (out of zone) has no addresses records (A o
r )
zone example/IN: loaded serial 0
OK
% cat test
@ IN SOA . . 0 0 0 0 0
@ IN NS .
@ IN MX 10 .
%
It's easy enough to remove the address checks for ..
what about check-mx setting, can it be also affected by this setting?
As I said it is a easy fix. This just copies what the srv check does.
Index: lib/dns/zone.c
===
RCS file: /proj/cvs/prod/bind9/lib/dns/zone.c,v
retrieving revision 1.574
diff -u -r1.574 zone.c
--- lib/dns/zone.c 6 Sep 2010 04:41:13 - 1.574
+++ lib/dns/zone.c 12 Nov 2010 22:08:51 -
@@ -1751,6 +1752,12 @@
int level;
/*
+* . means the services does not exist.
+*/
+ if (dns_name_equal(name, dns_rootname))
+ return (ISC_TRUE);
+
+ /*
* Outside of zone.
*/
if (!dns_name_issubdomain(name, zone-origin)) {
--
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: dynamic updates via libbind.
It would be interesting to have an API that we could use to make changes dynamically to DNS zones. I don't know if there is already such a tool. No dia 12 de Nov de 2010, às 18:57, Jack Tavares j.tava...@f5.com escreveu: I am currently using libbind to do dynamic updates in C. I have looked in the bind 9.7.x source and I don't see a replacement mechanism for this. Is there one or is there one planned in bind10? Thanks -- Jack. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC with 9.7.2-P2
In message 4cdd6467.9050...@imperial.ac.uk, Phil Mayers writes:
On 12/11/10 15:45, Lightner, Jeff wrote:
For Production (RPM based system) you should use RHEL or CentOS which
has a much longer life cycle. (Speaking of which, RHEL6 was just put in
I don't agree with your line of reasoning. RHEL may have longer update
cycles, but there's no guarantee a particular RHEL install will be
applying updates in real-time, so the keys in the dnssec-conf package
may still get out of date, or a RHEL install may run after it's 5-year
update cycle ends.
I think the dnssec-conf package should have had a nightly cron job to
refresh these keys, and it was a mistake to deploy without such.
Just my opinion of course.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
I use the following scripts (update-trusted-keys and commit-trusted-keys)
to manage my trust anchors. I run update-trusted-keys nightly from cron
and manually update when I get email that there has been a change.
update-trusted-keys replaces the trust anchor when the tld gets a DS
record added to the root zone. With no arguements it just updates the
current list of zones listed is /etc/trusted-keys.
To bootstrap the process run it with a . and the TLDs.
e.g.
/etc/update-trusted-keys . br org com net
and then add a include line to each zone to /etc/named.conf.
e.g.
include /etc/trusted-keys/ROOT;
include /etc/trusted-keys/br;
include /etc/trusted-keys/org;
include /etc/trusted-keys/com;
include /etc/trusted-keys/net;
Mark
/etc/update-trusted-keys:
#!/bin/sh -f
#
# The directory containing the trusted keys.
#
d=/etc/trusted-keys
# If we havn't been given a list of zones then get the list
# of zones from trusted-keys directory excluding files that
# may have been the result of mapping the zone name to something
# suitable for the file system.
#
if test ! -n $*
then
set `ls ${d}/ | grep -v .new | grep -v _ | sed 's/^ROOT$/./'`
fi
#
# For each zone attempt to get the DNSKEY RRset. This will be
# validated by the the nameserver before being returned to us.
# If there are keys with the KSK flag set then use them to create
# a new trusted-key set otherwise use all keys.
#
# Report when the trusted-key set has changed.
#
# Note: this code assumes that there is a proper key rollover
# where multiple keys are active for a significant amount of time
#
for i in $@
do
f=`echo ${i} | tr '[A-Z/ ]' '[a-z__]'`
n=.new-${f}
i=`echo ${i} | tr '[A-Z]' '[a-z]'`
case $i in
.) f=ROOT; n=.new-ROOT;;
*.) ;;
*) i=${i}.;;
esac
case ${i} in
.) DS=0;;
*) DS=`/usr/local/bin/dig +noall +answer DS ${i} @127.0.0.1 |
grep -v '^;;' | wc -l | sed 's/ *//g'`;;
esac
REM=
if test ${DS} -gt 0
then
if test `expr ${i} : '^[a-z0-9-][a-z0-9-]*\.$'` != 0
then
REM=//
fi
fi
/usr/local/bin/dig +noall +answer dnskey ${i} @127.0.0.1 |
sort |
awk -v DS=${DS} -v REM=${REM} '
BEGIN {
ksks = ;
zsks = ;
}
$4 == DNSKEY $5 == 257 {
key = ;
for (i = 8; i = NF; i++) key = key $i;
if (key ~ /INVALID/) REM=// ;
ksks = ksks \t REM $1 $5 $6 $7 \ key \;\n;
next;
}
$4 == DNSKEY $5 == 256 {
key = ;
for (i = 8; i = NF; i++) key = key $i;
if (key ~ /INVALID/) REM=// ;
zsks = zsks \t REM $1 $5 $6 $7 \ key \;\n;
}
END {
if ( ksks != ) {
print trusted-keys {
if (DS != 0)
print \n\t/* DS DS records found. */\n;
print ksks };;
} else if (zsks != ) {
print trusted-keys {
if (DS != 0)
print \n\t/* DS DS records found. */\n;
print zsks };;
}
}
' ${d}/${n}
#
# Test to see if we actually wrote anything.
#
if test -s ${d}/${n}
then
if ! test -f ${d}/${f}
then
touch ${d}/${f}
fi
diff -u ${d}/${f} ${d}/${n}
elif test -s ${d}/${f}
then
diff -u ${d}/${f} ${d}/${n}
fi
done
cd /etc
fetch -qm https://www.ripe.net/projects/disi/keys/ripe-ncc-dnssec-keys-new.txt
diff -u ripe-ncc-dnssec-keys.conf ripe-ncc-dnssec-keys-new.txt
/etc/commit-trusted-keys:
#!/bin/sh
RE: DNSSEC with 9.7.2-P2
Lads,
Isn't this getting ridiculous?
Is this the future of DNSSEC?
Ian
-Original Message-
From: bind-users-bounces+ian.t=thoughtbubble@lists.isc.org
[mailto:bind-users-bounces+ian.t=thoughtbubble@lists.isc.org] On
Behalf Of Mark Andrews
Sent: 13 November 2010 00:36
To: Phil Mayers
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC with 9.7.2-P2
In message 4cdd6467.9050...@imperial.ac.uk, Phil Mayers writes:
On 12/11/10 15:45, Lightner, Jeff wrote:
For Production (RPM based system) you should use RHEL or CentOS
which has a much longer life cycle. (Speaking of which, RHEL6 was
just put in
I don't agree with your line of reasoning. RHEL may have longer update
cycles, but there's no guarantee a particular RHEL install will be
applying updates in real-time, so the keys in the dnssec-conf package
may still get out of date, or a RHEL install may run after it's 5-year
update cycle ends.
I think the dnssec-conf package should have had a nightly cron job to
refresh these keys, and it was a mistake to deploy without such.
Just my opinion of course.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
I use the following scripts (update-trusted-keys and
commit-trusted-keys) to manage my trust anchors. I run
update-trusted-keys nightly from cron and manually update when I get
email that there has been a change.
update-trusted-keys replaces the trust anchor when the tld gets a DS
record added to the root zone. With no arguements it just updates the
current list of zones listed is /etc/trusted-keys.
To bootstrap the process run it with a . and the TLDs.
e.g.
/etc/update-trusted-keys . br org com net
and then add a include line to each zone to /etc/named.conf.
e.g.
include /etc/trusted-keys/ROOT;
include /etc/trusted-keys/br;
include /etc/trusted-keys/org;
include /etc/trusted-keys/com;
include /etc/trusted-keys/net;
Mark
/etc/update-trusted-keys:
#!/bin/sh -f
#
# The directory containing the trusted keys.
#
d=/etc/trusted-keys
# If we havn't been given a list of zones then get the list
# of zones from trusted-keys directory excluding files that
# may have been the result of mapping the zone name to something
# suitable for the file system.
#
if test ! -n $*
then
set `ls ${d}/ | grep -v .new | grep -v _ | sed 's/^ROOT$/./'`
fi
#
# For each zone attempt to get the DNSKEY RRset. This will be
# validated by the the nameserver before being returned to us.
# If there are keys with the KSK flag set then use them to create
# a new trusted-key set otherwise use all keys.
#
# Report when the trusted-key set has changed.
#
# Note: this code assumes that there is a proper key rollover
# where multiple keys are active for a significant amount of time
#
for i in $@
do
f=`echo ${i} | tr '[A-Z/ ]' '[a-z__]'`
n=.new-${f}
i=`echo ${i} | tr '[A-Z]' '[a-z]'`
case $i in
.) f=ROOT; n=.new-ROOT;;
*.) ;;
*) i=${i}.;;
esac
case ${i} in
.) DS=0;;
*) DS=`/usr/local/bin/dig +noall +answer DS ${i} @127.0.0.1 |
grep -v '^;;' | wc -l | sed 's/ *//g'`;;
esac
REM=
if test ${DS} -gt 0
then
if test `expr ${i} : '^[a-z0-9-][a-z0-9-]*\.$'` != 0
then
REM=//
fi
fi
/usr/local/bin/dig +noall +answer dnskey ${i} @127.0.0.1 |
sort |
awk -v DS=${DS} -v REM=${REM} '
BEGIN {
ksks = ;
zsks = ;
}
$4 == DNSKEY $5 == 257 {
key = ;
for (i = 8; i = NF; i++) key = key $i;
if (key ~ /INVALID/) REM=// ;
ksks = ksks \t REM $1 $5 $6 $7 \ key
\;\n;
next;
}
$4 == DNSKEY $5 == 256 {
key = ;
for (i = 8; i = NF; i++) key = key $i;
if (key ~ /INVALID/) REM=// ;
zsks = zsks \t REM $1 $5 $6 $7 \ key
\;\n;
}
END {
if ( ksks != ) {
print trusted-keys {
if (DS != 0)
print \n\t/* DS DS records found.
*/\n;
print ksks };;
} else if (zsks != ) {
print trusted-keys {
if (DS != 0)
print \n\t/* DS DS records found.
*/\n;
print zsks };;
}
}
' ${d}/${n}
#
# Test to see if we actually wrote anything.
#
if test -s ${d}/${n}
then
if ! test -f ${d}/${f}
then
touch
hello bind network problem ipv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hello bind network hello guru of bind hello everybody i have all a slice of ipv6 address 2001:41D0:2:3Dd6::/64 and I would simply change it with my bind ipv6 please you have to be in your answer or I will not understand Please give concrete examples of config bind otherwise I would not understand very nice for all answers even the direct mailer in my mailbox - -- http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org/ iD8DBQFM3euftXI/OwkhZKcRAn9XAJ9yhjDo1C+Et/PYsloD7V8qXnD4IQCggMVn Al19iQHuOfqsGYDepFT60QA= =egd8 -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
