dnssec-lookaside != auto
Hello everyone,
I've recently updated bind to version 9.7.2_p3.
I've been using DLV before that, specifically dlv.isc.org, with two
entries in named.conf
options {
dnssec-lookaside . trust-anchor dlv.isc.org.;
};
trusted-keys{
[sometext]
};
and it was working fine.
However, on update I've wanted to try managed-keys. so changed
trusted-keys to managed-keys (and added initial key of course)
so the relevant part of config file now looks like this:
managed-keys {
dlv.isc.org. initial-key 257 3 5
"BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
};
this has caused problem, every query caused error, no answers and these
log entries:
Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org
DNSKEY: must be secure failure, . is under DLV (startfinddlvsep)
Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving
'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53
After some googling and finding
http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html
and even better
http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html
I've changed to dnssec-lookaside auto. Lo and behold, everything works fine.
However, this presents the following problems to me:
- managed keys does not work as advertised:
In bind manual (PDF downloaded from http://www.bind9.net/manuals), it's
said that managed-keys is similar to trusted-keys, but where key in
trusted-keys is static and trusted as long as it's in config file, key
in managed-keys is trusted only once, to download this key and store it
in trusted database. This proves to be wrong, as it's not trusted even
that one time.
- I don't seem to be able to switch to another DLV registry.
dnssec-lookaside accepts only auto, so I have no choice but to use
built-in DLV. But, e.g. secspider.cs.ucla.edu looks interesting.
Can anyone shed some light if this is my mistake, not having something
in configuration, or a general bind error?
Regards,
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
On 12/20/10 01:32, Mark Andrews wrote:
> In message <4d0e8340.9060...@data.pl>, Torinthiel writes:
>
>> Hello everyone,
>>
>> I've recently updated bind to version 9.7.2_p3.
>>
> Upgraded from what?
>
>From 9.4.3_p5
>
>
>> I've been using DLV before that, specifically dlv.isc.org, with two
>> entries in named.conf
>>
>> options {
>> dnssec-lookaside . trust-anchor dlv.isc.org.;
>> };
>> trusted-keys{
>> [sometext]
>> };
>>
>> and it was working fine.
>> However, on update I've wanted to try managed-keys. so changed
>> trusted-keys to managed-keys (and added initial key of course)
>>
>> so the relevant part of config file now looks like this:
>>
>> managed-keys {
>> dlv.isc.org. initial-key 257 3 5
>> "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
>> brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
>> 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
>> ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
>> Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
>> QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
>> };
>>
>>
>> this has caused problem, every query caused error, no answers and these
>> log entries:
>>
>> Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org
>> DNSKEY: must be secure failure, . is under DLV (startfinddlvsep)
>> Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving
>> 'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53
>>
> And what other errors were logged by named when it started?
>
None. Complete startup log sequence:
Dec 20 07:49:14 sarlac named[4137]: loading configuration from
'/etc/bind/named.conf'
Dec 20 07:49:14 sarlac named[4137]: reading built-in trusted keys from
file '/etc/bind/bind.keys'
Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv4 port range:
[1024, 65535]
Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv6 port range:
[1024, 65535]
Dec 20 07:49:14 sarlac named[4137]: set up managed keys zone for view
_default, file 'managed-keys.bind'
Dec 20 07:49:14 sarlac named[4137]: reloading configuration succeeded
Dec 20 07:49:15 sarlac named[4137]: managed-keys-zone ./IN: loaded serial 16
Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: loaded serial
2010110801
Dec 20 07:49:15 sarlac named[4137]: reloading zones succeeded
Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: sending
notifies (serial 2010110801)
>
>
>> After some googling and finding
>> http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html
>> and even better
>> http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html
>>
>> I've changed to dnssec-lookaside auto. Lo and behold, everything works fine.
>>
> And the contents of /etc/bind.key are? Also the contents in the
> chroot area if you are using chroot.
>
Changed /etc/bind.keys to /etc/bind/bind.keys, via config (and it reeds
it, you can see in logs). Contents were given in first post, only I
haven't mentioned it was in /etc/bind/bind.keys.
The managed-keys statement is the sole statement in /etc/bind/bind.keys
and is not present in main config file.
Ok, this was the problem. Having included the file as well as specified
it at bindkeys-file seems to have solved the problem. Ok, now the
documentation seems a bit unclear about it. It never states that the
file is included nor that it's not. But having information that it loads
the given file (in dnssec-lookaside description) and information that
file is loaded in logs has given me a false sense of security in this
case. Is this double-include (sort of) configuration what I was supposed
to do? Will it work correctly after a key rollover?
Also, another question arises: can one include more than one
bindkeys-file and/or dnssec-lookaside in config? The documentation hints
that at least the latter is possigble, but does not state so. And having
multiple bindkeys-file is useful if you have locally-configured keys,
for which using the main file is not recommended.
Skipping rest of answers, as problem is (mostly) solved.
Regards,
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Does anyone know where to find the ISC signing keys for source packages?
Thomas Schulz pisze: >> On 12/23/2010 4:09 PM, Casey Deccio wrote: >> >>> On Thu, Dec 23, 2010 at 12:49 PM, Oisin McGuinness >>> wrote: >>> >>> >>>> But I can't find any reference to current PGP or other signing keys; does >>>> anyone know where to find >>>> them on the www.isc.org web site or where to obtain them otherwise? >>>> >>> http://www.isc.org/about/openpgp >>> >> https://www.isc.org/about/openpgp will work as well. >> >> -- >> Dave >> > > It looks like I am a little dim today. Given gpg and the key, what steps > do I do to verify a source package? > First, you get the tarball and the signature from isc.org (say http://www.isc.org/software/bind/972-p3/download/bind-972-p3targz ) Second, you issue gpg --verify bind-9.7.2-P3.tar.gz.asc bind-9.7.2-P3.tar.gz might work with only the signed name (gpg --verify bind-9.7.2-P3.tar.gz.asc), I'm not sure how about this case. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
Dnia 2010-12-28 09:26 Eivind Olsen napisał(a): >> >> trying to resolve www.microsoft.com or microsoft.com results in a >> >> "connection timed out; no servers could be reached" >> > > > >Well, for what it's worth - it's not just you having that issue. When > >testing from home and from work I get the same. > > > >Of course, I could be doing something wrong, but whenever I see an error I > >like to imagine it's somebody elses fault :D > > > >One of the nameservers for microsoft.com is ns1.msft.net with an IP > >address of 65.55.37.62. For some reason the response I get from it is > >truncated, and retrying using TCP doesn't work. Using EDNS0 also doesn't > >seem to work, I get FORMERR back: > [cut long listing of DNS tries] Same here, I cannot reach this server with TCP or EDNS, nor get longer replies (al with dig), nor can bind resolve it locally (although it works with simple A query) Confirmed, I can get TCP and EDNS replies from a.ns.se Gentoo, bind version 9.7.2_p3, server located somewhere in France, in OVH network. > >So, to recap: at the risk of showing what a fool I am by doing something > >completely wrong here, I'm betting Microsoft has messed up their DNS - I > >would have expected queries over TCP to work, and I would not have > >expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement > >EDNS, giving a FORMERR is apparantly the right thing to do). > Not being a bind expert myself (but having read and hopefully understood the RFC's) I have to agree with it. And, having other issues with Microsoft DNS server myself (althoug this could be the lameness of it's admins as well), I don't have a hard time believing this. Although, if it works when VM is duplicated but has no traffic, it looks like something else to me (maybe two completely different errors, but with similar apperance) Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto update signatures dnssec
fakessh @ pisze:
>>> zone "fakessh.eu" {
>>> type master;
>>> file "/var/named/fakessh.eu.hosts";
>>> auto-dnssec maintain;
>>> update-policy local;
>>> key-directory "/var/named/keyset-fakessh.eu";
>>> allow-transfer { 213.251.188.140;87.98.164.164;
>>> 195.234.42.1;94.23.59.30; };
>>> };
>>>
>>> is what the guidelines are good options
>>>
> hello responsible bind community.
>
> you gave me the answer, thank you to my question but I am having new
> problems.
>
> I encounter errors during the self resignatures
>
> i quote my multiple error :
>
> I do not know what it is
>
>
>
[cut most log entries]
> Dec 28 22:04:02 r13151
> named-sdb[24511]: /var/named/renelacroute.fr.hosts.jnl: create:
> permission denied
> Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
> reading private key file fakessh.eu/DSA/9552: file not found
> Dec 28 22:04:02 r13151 named-sdb[24511]: dns_dnssec_findzonekeys2: error
> reading private key file fakessh.eu/DSA/47103: file not found
>
First, where are the key files, related to bind directory (the one in
options { directory })?
Are the names correctly given to bind?
it looks like bind cannot find them.
Second, you need to give the user runing bind (probably named) rights to
write to /var/named/renelacroute.fr.hosts.jnl directory.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
Ok, trying to send the same email third time, maybe it will get to the right recipient and with the right subject at last. Damn webmail, damn trying to resend from thunderbird. Dnia 2010-12-28 09:26 Eivind Olsen napisał(a): >> >> trying to resolve www.microsoft.com or microsoft.com results in a >> >> "connection timed out; no servers could be reached" >> > > > >Well, for what it's worth - it's not just you having that issue. When > >testing from home and from work I get the same. > > > >Of course, I could be doing something wrong, but whenever I see an error I > >like to imagine it's somebody elses fault :D > > > >One of the nameservers for microsoft.com is ns1.msft.net with an IP > >address of 65.55.37.62. For some reason the response I get from it is > >truncated, and retrying using TCP doesn't work. Using EDNS0 also doesn't > >seem to work, I get FORMERR back: > [cut long listing of DNS tries] Same here, I cannot reach this server with TCP or EDNS, nor get longer replies (al with dig), nor can bind resolve it locally (although it works with simple A query) Confirmed, I can get TCP and EDNS replies from a.ns.se Gentoo, bind version 9.7.2_p3, server located somewhere in France, in OVH network. > >So, to recap: at the risk of showing what a fool I am by doing something > >completely wrong here, I'm betting Microsoft has messed up their DNS - I > >would have expected queries over TCP to work, and I would not have > >expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement > >EDNS, giving a FORMERR is apparantly the right thing to do). > Not being a bind expert myself (but having read and hopefully understood the RFC's) I have to agree with it. And, having other issues with Microsoft DNS server myself (althoug this could be the lameness of it's admins as well), I don't have a hard time believing this. Although, if it works when VM is duplicated but has no traffic, it looks like something else to me (maybe two completely different errors, but with similar apperance) Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.2-P3 does not resolve www.microsoft.com
Dnia 2010-12-29 13:55 T. Wunderlich napisał(a): >Thanks a lot for all your suggestions. I haven't found a solution yet, but found something >which got my attention: > >Have a look at the TTL of the following CNAME entries. > >What happens when the lookup lasts longer than those 57 seconds? Maybe named will get >in trouble then? Wow, a lookup that takes more than 57 seconds? Now that's a lng query, even on a busy server. Anyway, if you happen to ask the server second time after 56 seconds, than that's more probable. I guess it should work correctly nonetheless. > >AND what do the RFC say about those CNAME chains? CNAME points to a CNAME? It's not incorrect, but discouraged. See http://tools.ietf.org/html/rfc1034, last two paragraphs of section 3.6.2 Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Dnia 2010-12-30 18:03 p...@mail.nsbeta.info napisał(a): >Sunil Shetye writes: > >> >> Case 2: Lame Server Reply >> >> === >> $ dig +norecurse @a.iana-servers.net. example.org. >> ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;example.org.IN A >> >> ;; ANSWER SECTION: >> example.org. 172800 IN A 192.0.32.10 >> >> ;; AUTHORITY SECTION: >> example.org. 172800 IN NS ns1.example.org. >> example.org. 172800 IN NS ns2.example.org. >> === >> >> This is a lame server reply. bind ignores this reply. bind will give a >> server fail reply to the client. >> > > >Would you please tell me why this is a lame server reply? why bind will >give a server fail reply to the client? Thanks again a lot. Because it's contrary to itself. You've specified norecurse, which means that if nameserver believes it has authorative data it should return it, if it doesn't it should return a referral (and no answer beside it). But the server returns answer (which means it believes it has authorative data), but in authority section is not listed in nameservers, which states it does not have authorative data. To sum up: Question: Does the server have authorative data? Answer 1: Server returns data when asked without recursion ->; YES Answer 2: Server is not listed in authority section ->; NO Real answer: Lame server. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Dnia 2010-12-30 19:18 p...@mail.nsbeta.info napisał(a): >Please see this dig: > >$ dig +norec dev.game.yy.com @202.96.128.166 > >; <<>> DiG 9.4.2-P2 <<>> +norec dev.game.yy.com @202.96.128.166 >;; global options: printcmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31949 >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > >;; QUESTION SECTION: >;dev.game.yy.com. IN A > >;; ANSWER SECTION: >dev.game.yy.com.1800IN A 202.104.186.179 > >;; Query time: 5 msec >;; SERVER: 202.96.128.166#53(202.96.128.166) >;; WHEN: Thu Dec 30 19:16:44 2010 >;; MSG SIZE rcvd: 49 > > >So, is 202.96.128.166 a lame server? There's something strange with this one. You've specified +norec on command line, but the query was sent with 'rd' - 'recursion desired' flag, as if you haven't given +norec. And with recursion giving answer is perfectly legal. If not for that flag, then yes, I'd consider it a lame response, although probably someone more knowledgeable than me should judge this. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Dnia 2010-12-30 11:45 Torinthiel napisał(a): >Dnia 2010-12-30 18:03 p...@mail.nsbeta.info napisał(a): > >>Sunil Shetye writes: >> >>> >>> Case 2: Lame Server Reply >>> >>> === >>> $ dig +norecurse @a.iana-servers.net. example.org. >>> ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;example.org. IN A >>> >>> ;; ANSWER SECTION: >>> example.org.172800 IN A 192.0.32.10 >>> >>> ;; AUTHORITY SECTION: >>> example.org.172800 IN NS ns1.example.org. >>> example.org.172800 IN NS ns2.example.org. >>> === >>> >>> This is a lame server reply. bind ignores this reply. bind will give a >>> server fail reply to the client. >>> >> >> >>Would you please tell me why this is a lame server reply? why bind will >>give a server fail reply to the client? Thanks again a lot. > >Because it's contrary to itself. >You've specified norecurse, which means that if nameserver believes it has >authorative data it should return it, if it doesn't it should return a >referral (and no answer beside it). > >But the server returns answer (which means it believes it has authorative >data), but in authority section is not listed in nameservers, which states >it does not have authorative data. > >To sum up: >Question: Does the server have authorative data? >Answer 1: Server returns data when asked without recursion ->; YES >Answer 2: Server is not listed in authority section ->; NO >Real answer: Lame server. And I was wrong about that one. There are two issues with that one. First, I get a different response from that command. different flags (no ra but aa instead), differend authority section. It's much simplier to tell if it's a 'lame nameserver response' although it can't be judged by a single query. Let's say that nameservers for .org domain (there are a lot of them), when asked for example.org give a.iana-servers.net and b.iana-servers.net (which is true, and by itself nothing special). Then lets assume (which is not true, but a good example) that a.iana-servers.net when asked for www.example.org gives something (doesn't matter if a true answer, or missing record, or anything), but with 'aa' flag not set. This, by itself, is still nothing special, no server is required to know everything. But from those two answers you have a contradiction, and this contradiction is a real lane nameserver issue. .org servers delegate answers to a.iana-servers.net, and a.iana-servers.net fails to deliver authorative response. So the delegation is in fact incorrect. Fortunately, a.iana-servers.net does not behave the way I've described here and does set 'aa' flag in it's response. Hope this clears up the issue a bit, and reduces misinformation caused by my previous answer. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind replication
Dnia 2010-12-31 09:58 Nuno Paquete napisał(a): > >No dia 31 de Dez de 2010, às 08:18, "p...@mail.nsbeta.info" escreveu: > >> Anand Buddhdev writes: >>> On 31/12/2010 05:33, p...@mail.nsbeta.info wrote: >>>> Hi, >>>> Is it a right way to run rsync for bind's zone files replication? >>>> If we have dozons of zones, each zone has more than one view, under this >>>> case setup the master/slave with standard zone-traff is the hard way IMO. >>>> Thanks. >>> Yes, that's just fine. You don't have to use zone transfers. >> >> Thanks. But I have another question, >> how would bind know the zone files were changed before it reload zones? >> Regards. > >I think you have to restart bind. That's why I believe it's better to use zone transfers because it's automatic. No, you don't have to. If you know which zone has changed, than you can do "rndc reload zonename". If you don't, than "rndc reload" reloads all zones. You could also try "rndc reconfig", but I think it will only load new zonesm the ones just added in configuration, not never wersions of old zones). Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Entired NS crashed
Michelle Konzack pisze: > As far as I can see, 'dig +dnssec www.tamay-dogan.net' give a nice output > but how can I know, the expiration date? > > Is this the timestamp here: > > tamay-dogan.net.3600IN RRSIG SOA 5 2 3600 20110131191903 > Nope > [ command 'dig +dnssec tamay-dogan.net' ]--- > tamay-dogan.net.3600IN SOA dns1.tamay-dogan.net. > hostmaster.tamay-dogan.net. 1292829280 10800 3600 604800 86400 > tamay-dogan.net.3600IN RRSIG SOA 5 2 3600 20110131191903 > 20110101191903 12795 tamay-dogan.net. > lti7l2JlLeIATApQfWp3BdPTH4MiP75crl4921bC1qdOXfWJH4La+L58 > t0hVMmzNaNbLDH36cQwrYdQvaBJHPkQEwi2Mr8WP0jCSp+bpc2lEP6sz > f+kRGWYITjuxAwFsSdhVR+EQd4pIupa16ylJ65OWcBGlIHbC5eA5KSN4 lTk= > The RRSIG here has two numbers 20110131191903 20110101191903. Look at it carefully: 2011-01-31 19:19:03 Looks like a date? The first one is when this signature ends to be valid, the second when it starts, both in UTC time. So in this case your signature on the SOA record is valid almost all of January. There's nothing stopping you from having different vaility periods on different signatures, it's all per-signature. > tamay-dogan.net.86400 IN NSECadmin.tamay-dogan.net. NS SOA > MX TXT RRSIG NSEC DNSKEY > tamay-dogan.net.86400 IN RRSIG NSEC 5 2 86400 20110131191903 > 20110101191903 12795 tamay-dogan.net. > YS5Y44ywYrsjbSJmtFgF9hk8K80VWLuyLRuDxLeO84kXA/hN9i8mzzDy > XYIoiUwWbyeKxEIhqAdA6gekLU2Z+ZuNsSGnPUcCdfZD+GiWEneeWGg/ > LcIi9FWTf7J++yGnVMA5Ng6vZ3SgTtiC7r74ZZytm7FkijxCwd8tRyKy a9c= > > > which I could grep? And what is NSEC entry? > Why is the VHost there? > And the NSEC is used in authenticated denial of existence. It tells that there are NS, SOA etc recors with name tamay-dogan.net, and that next name with any content is admin.tamay-dogan.net. So, if eg you've asked for abyss.tamay-dogan.net the NS could present you with this RR and it's signature and prove that abyss.tamay-dogan.net (which falls between tamay-dogan.net and admin.tamay-dogan.net) does not exist. As a side effect, it's now possible to enumerate every record your zone. If you're concerned about this, consider switching to NSEC3, which makes it much harder. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 ISSUE
On 01/07/11 14:25, rams wrote: > I have trouble resolving the host name dnssecnsec3qatestdomain.com > <http://dnssecnsec3qatestdomain.com>. which is NSEC3 signed. > This is the > parent and child zone. If I run dig ( dnssec query) with the +cd option > I which is a proper response: What version of bind are you using? My wild guess is that it's not recent enough to recognize NSEC3 signatures. Bind 9.4.3 was not, and I got exactly the same symptoms. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9 multiple masters setup
On 01/12/11 16:13, dev null wrote: > Hello, > > I have most of this worked out but I intend to setup bind in a > multiple master manner. > > This makes me question a few things: > > 1. What can I use for the SOA MNAME? In the off chance a box may die, > I am thinking of using a VIP which contains the multiple masters > within it. However I am not sure how this would affect NOTIFY. So can > I use a VIP or do I just use one of the master DNS boxes in the SOA > MNAME field? It's mostly ignored. All resolvers go for the NS records at the zone apex, not for MNAME. Even if the server named in MNAME dies, it won't affect resolving. You just rebuild that machine, or even build another one and change slaves to get data from new master. > 2. With that said, I intend to use rndc to push out DNS changes, > should I worry about using a VIP still? I may need to use both and > NOTIFY seems like it is more built-in so I want to keep rndc and > NOTIFY going. Isn't it simplier to just let BIND do it's job? When master loads a changed zone, it sends NOTIFY messages to slaves, and slaves seeing that they have outdated zone files download the zone from master. rndc can only tell BIND (either master or slave) to initiate that connection, it can't change zones by itself. You could of course copy zone files to slaves by some means (rsync? scp?) and then rndc reload the slave, but a) why? b) it really isn't a slave anymore, at least not in DNS terms. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC's sorted zone
On 01/12/11 17:58, Mark Elkins wrote: > Still playing with DNSSEC and signing zones. > > I'm resigning an already signed zone. > > I'm doing this on a hyper-threaded 4-core i7 (Intel(R) Core(TM) i7 CPU > 920 @ 2.67GHz) which under linux gives me 8 cores. > > I'm using the command: > > dnssec-signzone -3 "abcd" -o example.com -p -t -A -d keyset -g -a -N > increment -s 2011061553 -e 20110210161553 -f example.com.sign-1 > example.com.signed > > A minute later - I run the same command - but output to a different > file... -f example.com.sign-2 > > A 'diff' of the two output files gives lots of differences - apart from > the zone creation time. > > If I include the "-n ncpus" as "-n 1" - then the files are the same > (except for the creation time). > > I believe that the data is fundamentally the same - but it is partially > re-ordered if there are multiple threads. This is not what I would have > expected - having had it been drummed into me that dnssec-signzone will > first sort the zone then generate all the RRSIG records - etc... > I find this disturbing. It appears to only be doing this on CNAME > records. > > In one file: > www.access.example.com CNAME www.entry.example.com > access.example.com CNAME entry.example.com > > In the next - their order is swapped. > > > Are these differences in ordering completely ignored when BIND loads the > file into memory? Yes, order is completely ignored. Not only by BIND, but by ANY decent server. Try digg'ing any zone with numerous records for an answer, and you will get them in random order every time. It's supposed to be that way, that's how DNS works. If order is the only difference in those files, ignore it. More differences would be if you'd have omitted -s and -e, as it would put current time in the RRSIG, and as RRSIG's signature includes validity dates as well, than signature would be totally different. Also I haven't used -p, maybe it causes both zones to have same random data and thus same signatures. Besides, dnssec-signzone doesn't have to sort the zone at once. It only has to sort zone for generating NSEC records. All RRSIGs can be generated without sorting. Of course RRSIGs on NSEC need NSEC, so indirectly need sorting too. For NSEC3 (which you are using) sorting makes no sense. Signing only needs to sort hashed names to generate NSEC3 records. No need to sort actual records in zone. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Keys - and trying to not leaving them around
On 01/12/11 16:07, Mark Elkins wrote: >--- > > So now I want to resign the zone. Its already signed. How can I do that > without having to have the Private KSK still around. I'd have thought > that I'd just perhaps need the Private ZSK around to re-sign new zone > data. > > (here I removed the KSK Private file - 9983) > I think this works - but I get the message: > dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading > private key file example.com/NSEC3RSASHA1/9983: file not found > > So why is dnssec-signzone worried about the private part of a KSK that > it (I believe) should not need? Bug? Because it tries to resign whole zone, with new validity period. That's why it needs KSK. You could try passing it the previously-signed message, and add -i parameter. However, see below why this is not necessary a good idea. > > > > My zone changes quite a bit - so what I was thinking to do is Sign a > very basic copy of the zone (SOA, NS records - not much else) - then > move the Private KSK's off the disk completely - then add in my > "dynamic" data and re-sign as often as I need (whenever my "dynamic" > data changes) with just my Private ZSK available. KSK is only used to sign DNSKEY records. SOA, NS and everything else are signed by ZSK. > After about 6 month (whatever) - I can then create a new KSK - bring > back my original 'off-disk' Private KSK - sign a new basic copy of my > zone - take the two Private KSK's offline and go through the whole KSK > roll-over process. ie - I only have the private part of the KSK on the > disk for a very short time - usually its off-site. I should be able to > generate my very basic zone on a completely different server - perhaps > not connected to the Internet at all - and just (via USB stick) copy > over the basic signed zone every six months? You definitely can generate signatures offline. That's what's done for the root zone. But watch for one thing. You don't need to change KSK every time you re-sign your zone. Changing the KSK requires some good timing, changing the DS records in parent zone (if you publish them, and good odds that you don't control the parent zone, only have some web/email/phone interface to change your record) and informing all DLV repositories you might be in and everyone that has configured your key as a trust anchor. That's not something you want to do often. What you also don't want, is long signature periods. Why? Because for as long as a signature is valid, an attacker can pretend to anyone in the Internet that your zone hasn't changed. E.g. you move your web server from 1.2.3.4 to 4.3.2.1, update zone files, test that it works. But an attacker has your older A and RRSIG records, and can present them to someone in place of your correct answers. The receiver sees this response, verifies RRSIG (it validates, after all you've created it) and believes you still have 1.2.3.4 address. Now, thin about what happens if the DNSKEY record gets attacked this way, and you've changed it because your ZSK got stolen. As long as signature is valid you're vulnerable. Better, generate a range of signatures for DNSKEY with your KSK, say one for each month' and keep those RRSIGs secret for now. Guard them the same way you guard ZSK, but in different place, and release them into the zone file only when needed. That way if ZSK gets compromised you just scrap those signatures, generate new ZSK and new signatures. Just don't put those signatures with ZSK. It it gets compromised so do the signatures, and you're screwed. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to proper include DS record on key dnssec
Dnia 2011-01-14 03:11 fakessh @ napisał(a): >hello bind network and hello dnssec network admin. > > >thank you for answered, >I think I found a solution to my problem. >$INCLUDE directive is that I have to handle > > >example: > $INCLUDE /var/named/keys/dsset-fakessh.eu. fakessh.eu YOU don't do it. This goes into the PARENT zone. Unless you manage the parent zone as well, but even in that case it goes into a different file. >$INCLUDE /var/named/keys/keyset-fakessh.eu. fakessh.eu This is OK, although when you have an $INCLUDE and do dnssiec-signzone it automatically resolves it, so generated signed zone does not habe $INCLUDE >and perform a complete resignatures area zone >this should enable me to have the flag DS and DS sign, DLV and DLV sign Err, both the DS (as stated before) and DLV go into different zones. To sum up: DNSKEY goes to fakessh.eu DS goes to .eu, and I don't have any idea if registrars already permit it DLV goes to dlv.isc.net or any other dlv repository you want. That's three different zones, and three different signers. >in my area zone > >its right > >thanks for your return many return are welcome > > >Le jeudi 13 janvier 2011 à 12:36 -0500, Paul Wouters a écrit : >> On Thu, 13 Jan 2011, fakessh @ wrote: >> >> > I correctly configure my server centos dnssec on with as a >> > representative of encryptions dlv isc. my question is relevant and was >> > already asked but I have not found the complete answer on google. my >> > question is how to include the DS record in the Keys. my keys are in a >> > separate folder. the DS record is already generated in >> >> The DS record goes into the parent zone, not the zone itself. >> >> > I also wonder the utility of this good record given that my signatures >> > are marked as good on dlv >> >> Use any public DNS server with dlv configured. eg nssec.xelerance.net: >> >> dig +dnssec -t ds yourzone @nssec.xelerance.net >> >> > what file in the include directive must be accomplished and realize how >> > well inclusion of the DS record (what should be the proper syntax on how >> > to declare dlv isc) how to re-sign after the keys >> >> You give your DS via http://dlv.isc.org/ >> >> Paul >-- >gpg --keyserver pgp.mit.edu --recv-key 092164A7 >http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: AW: Dns doctoring/dnsmasq -V on bind?
Dnia 2011-01-17 15:53 someone napisał(a): >If it *is* the only way... >It will result in a tough week... >Not what I wanted to hear indeed ;) Maybe having a zone file for external view, and sed'ing the IPs to get file for internal view would get you an easier to maintain solution? You still have to setup views, but then it will be easier when you change something. Torinthiel > >Ty. > > >-Ursprüngliche Nachricht- >Von: Phil Mayers [mailto:p.may...@imperial.ac.uk] >Gesendet: Montag, 17. Januar 2011 15:46 >An: someone >Cc: bind-users@lists.isc.org >Betreff: Re: AW: Dns doctoring/dnsmasq -V on bind? > >On 17/01/11 14:30, someone wrote: >> >> Running internal stuff over nat and the firewall is bad practice and >> should be avoided as it uselessly loads the firewall, increases the >> complexity of the rules and creates bottlenecks on a fast network >backbone. > >Ah, I see. I misunderstood what you were trying to do. I thought the things >you wanted to "doctor" were external IPs. > >> So again the question is: is there a way to do dns doctoring with bind >only? > >I think currently the only solution for bind is to use views and separate >copies of the zones with internal/external IPs. > >Not what you want to hear I'm sure. > >___ >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: get a domain's dns records
Dnia 2011-01-21 08:50 Barry Margolin napisał(a): >In article , > Joseph S D Yao wrote: > >> On Fri, Jan 21, 2011 at 02:19:45PM +0800, p...@mail.nsbeta.info wrote: >> > >> > I'm jsut curious, how does "who.is" know the dns records in my domain >> > (nsbeta.info)? >> > >> > The page shows some of my RRs exactly: >> > >> > http://who.is/dns/nsbeta.info/ >> >> >> The title of the page is, "Nsbeta.info DNS Lookup | Nameserver Lookup - >> Who.is - Who.is". They probably did just exactly that - DNS lookup. >> Anything in DNS is public information. > >But the nameservers for the domain don't allow public zone transfers. >So if you know the names in the zone you can look them up, but how did >the site list the names in his zone? My guess would be that they don't list the whole zone. Look what's there: nsbeta.info (dig any nsbeta.info) and some quite easy to guess prefixes: mail, test and www. And everything deduced from them, like names test.nsbeta.info and mail.nsbeta.info resolve to. Probably all questions asked with ANY recordtype I've tested on two other domains, and it looks like that - results show that common prefixes also include blog. And they have some filtering of results, as I have a * TXT record which didn't show up as blog entry. Actually dig any on my zone gives even more information - e.g. SPF record , which didn't show up on results. And they don't support third-level domains as well - asking form mail.nsbeta.info returns information about nsbeta.info Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward using CNAME record
Dnia 2011-01-25 10:18 Henry Hartley napisał(a): >My apologies if this gets to the list twice. I tried to post it through >the web interface but it seems to have been dropped by whatever >screening gets applied. > >I'm not sure if I've misunderstood the use of CNAME or if I've simply >done something wrong. > >I have two domains that I want to forward. One is working properly and >the other is not. In both cases I want users to enter a URL in their >browser (www.example.com) and be forwarded to a different system, where >the user has their site. In the working case, the forwarding it to >web.me.com so I have the following in my zone file: > >www.example.com. CNAME web.me.com. > >When you point your browser to www.example.com (obviously not >"example") the page on web.me.com loads properly but www.example.com is >still displayed in the address bar. > >In the second case, which is NOT working, I have a similar CNAME record >but instead of web.me.com, it's on tumblr.com. So, I have this (this is >the actual domain): > >www.ioanamorosan.com. CNAME ioanamorosan.tumblr.com. > >If you go directly to ioanamorosan.tumblr.com, the site loads, but if >you go to www.ioanamorosan.com, you get a tumblr.com 404 error page. The >browser still displays www.ioanamorosan.com in the address bar. > >So, is this a situation where web.me.com is set up to recognize >www.example.com properly but tumblr.com is not? Or what? > >Should I be able to do what I'm trying to do? No, not exactly. your name properly resolves to the same domain as ioanamorosan.tumblr.com. Your DNS setup is perfectly correct. But the web server is not configured to handle www.ioanamorosan.com. If you go to ioanamorosan.tumblr.com it handles the name correctly and gives your page. But when faced with a name it doesn't recognize it falls back to default site. If you have a web panel to configure your hosting, look for something named alternative domain names, aliases, virtual hosts or virtual servers. The name that is sent to the web serwer is the one typed in browser, and has nothing to do with any CNAME records on the way. The web server must be configured to handle it. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Globally setting TTL
Dnia 2011-01-26 00:21 Eivind Olsen napisał(a): >> Is it possible to globally set (override) the default TTL for all zones >> and their subsequent records? > >You're thinking about the authoritative zones you host? I am not aware of >any such setting, but it might be possible to use $INCLUDE in the >zonefiles and include a file which contains "$TTL 86400" or whatever. Try >it and see if that works for you :D You can still type $TTL 86400 in your zone file, which will have the same effect. (although might be harder to change for more zones). But still this is ony the default, if an entry contains it's own TTL it will take precedence. Other than sed'ing/awk'ing the zone files I see no other options. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive DNS problem
Dnia 2011-01-27 17:38 bangla desh napisał(a): > >Hello all, > >I am running Bind 9.7.1-p2 as recursive dns. I encountered this problem with >the domain hsbc.com.bd. When I dig hsbc.com.bd, it gives me a connection >timed out response. > [cut] > >I digged further about the problem as to what causes it. I found out that if >I clear the cache and then dig first the ns record(s) of com.bd, before I >dig hsbc.com.bd, I will be able to replicate the problem. can't reproduce it here, works for me when I try stright hsbc.com.bd, or dig ns com.bd beforehand, or dig both ns bd and com.bd. > >What bothered me is what is in com.bd that blocks the response from >hsbc.com.bd? Please I need your inputs. One thing for sure. It has only one nameserver. This is plainly wrong, each domain should have at least 2 (and SLD like this one even more). does it work when you type dig ns hsbc.com.bd @ns.com.bd because that's what fails for me. And there's more: $ dig ns com.bd @dns.bd ; <<>> DiG 9.7.1 <<>> ns com.bd @dns.bd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57519 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;com.bd. IN NS ;; ANSWER SECTION: com.bd. 86400 IN NS ns.com.bd. ;; ADDITIONAL SECTION: ns.com.bd. 86400 IN A 203.112.194.18 ;; Query time: 368 msec ;; SERVER: 209.58.24.3#53(209.58.24.3) ;; WHEN: Thu Jan 27 11:00:46 2011 ;; MSG SIZE rcvd: 57 $ dig ns hsbc.com.bd @dns.bd ; <<>> DiG 9.7.1 <<>> ns hsbc.com.bd @dns.bd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;hsbc.com.bd. IN NS ;; AUTHORITY SECTION: hsbc.com.bd. 86400 IN NS ns11.hsbc.com.hk. hsbc.com.bd. 86400 IN NS ns13.hsbc.com.hk. hsbc.com.bd. 86400 IN NS ns1.hsbc.com.sg. ;; Query time: 368 msec ;; SERVER: 209.58.24.3#53(209.58.24.3) ;; WHEN: Thu Jan 27 11:01:07 2011 ;; MSG SIZE rcvd: 107 Which means that DNS server for .bd domain (at leas one of them) returns answer for ns for .com.bd (ok, it is a delegation probably), but also a (non-authorative) answer for hsbc.com.bd. This is a bit strange, it doesn't provide recursive queries, it has delegation for com.bd, but it's still willing to return deeper answers. Now, what happens when you have clear cache is that it asks dns.bd for reference and gets hsbc records. But if you have NS com.bd in your cache, bind probably assumes (and quite correclty) that it shoud ask com.bd nameservers, not the bd. ones. But com.bd ones don't provide an answer, so you have timeout. Looks like the com.bd zone is broken somewhat. either the delegation should be removed from bd, or the server needs fixing and adding another servers is necessary. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive DNS problem
Dnia 2011-01-28 10:52 bangla desh napisał(a): >> I believed so that com.bd is broken. It only has 1 ns server and >hsbc.com.bd, whois.com.bd and even google.com.bd they are all delegate >directly from bd and not from com.bd. > >I am wondering, is there a dns rule/standard (or RFC) that explains about >delegation? For the fact that com.bd is broken - that's just how DNS works. Zone cuts are there for purpose. Most of this can be read from RFC 1034 and 1035, which form the grounds for DNS standards. Also RFC 2181 clarifies: A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone. And a mere presence of NS records indicates a zone cut (again, RFC 2181): The existence of a zone cut is indicated in the parent zone by the existence of NS records specifying the origin of the child zone. As for number of authorative servers per domain, I don't remember where, but at leas one RFC stated that there should be at least two, and preferably 3-7 nameservers per domain. It's quite possible that one of those I've already pointed to contains this information, but also that a different one states this information. But it was RFC for certain. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Some dnssec-signzone questions
I have three questions regarding dnssec-signzone: To clarify things, I'm using BIND 9.7.2-P2. First is about input file: you can specify on the command line either the signed version of the zone, or the unsigned one. What I'd like to do hovever, is to use both. The unsigned zone is much more readable, and can contain $INCLUDE directives, which makes modification easier. But specifying the signed zone has added benefit of reusing existing signatures, thus saving on computation time (not that I have a lot to save on ;). So, I'd like dnssec-signzone to take 'normal' records from non-signed zone, try to reuse RRSIG records as much as possible, taking them from signed zone, and write the result. Is this possible with dnssec-signzone? Other than writing a custom tool to filter only NSEC/RRSIG records from .signed and appending this file to unsigned zone? Which might not be that hard, probably a simple sed script would do. Another is about key management and -S option: Guessing by what I've read in the man page -S should use key metadata to decide when to include/exclude/use/revoke the key. However, I've been unable to make it work. I have 2 KSK keys, one of them set to revoke in the past, as dnssec-settime kindly tells me. But, when I do dnssec-signzone -S on the unsigned file, I get error message: dnssec-signzone: fatal: cannot find DNSKEY RRSIGs and nothing is signed. dnssec-signzone without -S can properly sign the zone, ignoring revokation time. Then, I do dnssec-signzone -S on the signed file, which only retains old signatures, also happily ignoring revokation time. What am I doing wrong, why it fails to behave as I'd expect? Third is about -N option: a well established practice (although I don't know what was the origin) is to set SOA serial number to eg 2011020101, which is current day and two-digit of daily version. This has benefit of being almost as good as putting unixtime of last modification, while being much more human-readable. How difficult would it be to implement this for dnssec-signzone -N, using a fourth format specifier? Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Some dnssec-signzone questions
On 02/01/11 19:44, Paul Wouters wrote: > On Tue, 1 Feb 2011, Torinthiel wrote: > >> >> To clarify things, I'm using BIND 9.7.2-P2. >> >> First is about input file: you can specify on the command line either >> the >> signed version of the zone, or the unsigned one. >> What I'd like to do hovever, is to use both. >> The unsigned zone is much more readable, and can contain $INCLUDE >> directives, >> which makes modification easier. >> But specifying the signed zone has added benefit of reusing existing >> signatures, thus saving on computation time (not that I have a lot to >> save >> on ;). So, I'd like dnssec-signzone to take 'normal' records from >> non-signed >> zone, try to reuse RRSIG records as much as possible, taking them from >> signed zone, and write the result. > > see ldns-read-zone -d (data without sigs) and ldns-read-zone -s (sigs > only) > combined with -n (dont print soa) for one of them. Thanks, nice tool. I'd have to look at ldns-* as I've only used drill from ldns packages. > > Basically run the signed zone through ldns-read-zone -s, concatenate it > with your unsigned zone, and run it through dnssec-signzone. Or have a script that either strips the data from signed zone or creates an empty file and then $INCLUDE that file in original unsigned zone. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Some dnssec-signzone questions
On 02/01/11 22:13, Jay Ford wrote: > On Tue, 1 Feb 2011, Torinthiel wrote: >> Third is about -N option: >> a well established practice (although I don't know what was the >> origin) is >> to set SOA serial number to eg 2011020101, which is current day and >> two-digit of daily version. This has benefit of being almost as good as >> putting unixtime of last modification, while being much more >> human-readable. >> How difficult would it be to implement this for dnssec-signzone -N, >> using a >> fourth format specifier? > > It's not hard. See my bind-users post of Oct 15 with subject: >more flexible serial number handling in dnssec-signzone > > Since then I've quit using the serial number fiddling ability of > dnssec-signzone. The problem is that it doesn't increment the serial > number > in the unsigned file, so future uses of "dnssec-signzone -N" could result > with the same or even lower values. Yes, that's a problem. Combined with ldns-read-zone and answer to my first question this could make dnssec-signzone read the good SOA record. I was also thinking of simply changing it by sed in a script. > > Instead, I created a zap-serial tool to zap the serial number in place > within > the unsigned zone file, either to a new literal value or incrementing > the old > number. My DNSSEC-related processes now zap the serial number before > signing > with dnssec-signzone. You can find the C source for zap-serial & some > possibly useful other DNSSEC-related scripts here (at least for now): >http://seatpost.its.uiowa.edu/bind_stuff Nice set of scripts. I was thinking of writing my own with probably similar functionality, but I'll start with those. Main difference is that I don't store keys online, so I'd like the scripts to notify me that signing is necessary instead of signing. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Dnia 2011-02-04 23:16 Jean-Yves Avenard napisał(a):
>Hi
>
>On 4 February 2011 22:54, Eivind Olsen wrote:
>
>> Unless I'm misunderstanding something, it should work. Here's an extract
>> from the BIND 9.7 ARM, section 6.2.16.2:
>>
>> "Forwarding occurs only on those queries for which the server is not
>> authoritative and does not have the answer in its cache."
>>
>> How exactly had you configured forwarding in your named.conf file?
>
>I use bind that comes with mac os 10.6 server (9.6.0-APPLE-P2);
>
>named.conf at the beginning includes a file options.conf.apple like so:
>options {
>include "/etc/dns/options.conf.apple";
>};
>
>options.conf.apple contains:
>directory "/var/named";
>
>forwarders { 203.59.24.3; 203.0.178.191; 203.134.24.70; };
>
>allow-transfer { none; };
>
>in named.conf I then have:
>include "/etc/dns/privateView.conf";
>
>which contains:
>view "intranet_view" {
>
>match-clients { 127.0.0.0/8; 192.168.0.0/23; };
>
> allow-recursion { "internal"; };
>
>zone "." {
>type hint;
> file "named.ca";
>};
>
>zone "domain.com" {
>type master;
> file "internal/db.domain.com";
> check-names ignore;
>notify TRUE;
> allow-update { key "rndc-key"; };
>// Cancel the forwarding for this authoritative domain.
>forwarders {
>};
>};
>
>On the other hand ; is the server authoritative for the sub-domain
>mel.domain.com provided I added the delegation ?
>digg shows something like:
>;; AUTHORITY SECTION:
>mel.domain.com.7200IN NS ad.domain.com.
This answer is not stating that it's authorative, but only that authorities
are below.
My wild guess ont what's happening, and why disabling forwarders fix this:
without NS m.domain.com is authorative for mel.domain.com, so it answers for
A mel.domain.com without issues.
Now, with NS, it's not authorative, as you've just set up a delegation. So,
when it receives the question it forwards it to one of three forwarding
servers. And they probably don't know how to access ad.domain.com (as it has
private IP adress, and these are public - that's one part of guess), they
end up not resolving the name.
Can verify that 203.59.24.3; 203.0.178.191; 203.134.24.70; can call
192.168.0.3, on that address?
Also, keep in mind that normally you should not use only one NS per
delegation, but a minimum of two. Here, for a testing environment (I guess)
it'll work, but don't do it on production environment.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: about the file command
Dnia 2011-02-08 17:40 Terry. napisał(a):
>Hi list,
>
>Can BIND's "file" command referer to more than one zone file?
>For example,
>
> zone "test.nsbeta.info" {
> type master;
> file "a.db";
> file "b.db";
> };
>
>When a record doesn't exist in a.db, BIND will continue to look for it in
b.db.
And when it exists in both? Take from a? take from b? take both?
And when there's A for a.example.com in a.db and MX for a.example.com in
b.db? Does this count as existing or not?
I don't think it's possible. can't you do cat a.db b.db > use_this.db or
$INCLUDE one of the files in the second?
or maybe ldns-read-zone to canonicalize records and then some awk to filter
from second zone only records that don't exist in first one.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
Dnia 2011-02-08 16:47 fddi napisał(a): >I need really something very simple: > > >I have 2 domain name servers, I need them to be multi-master so I will >put a mysql instance on each one, >the two mysql servers in sync whith each other. > >when one of the servers goes down, the other continue to work. > >There are very few entry in hte database let;s say 10 entries of >important internet services which must be >always avaliable... that's it nothing complicate. You really, really need a multi master for that? Like modyfing no both servers and/or unable to wait for the real master to go online? Because it looks like a normal slave configuration to me. Or, if you need to be able to modify records from both servers than maybe multi-master with rsync'ing to the other server will work? It's tricky, as you need to both rsync and then rndc reload, and remember to do it when you change anything OR the dead server goes up, but might be an option. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: syntax/format of zone on slave $ORIGIN/paragraph - sorted?
On 02/09/11 17:34, Walter Smith wrote: > Hello, > > I have bind/named running on Linux master and slaves. All is good, but > now when I’m trying to clean up some old records – I realized that > sorted zone on slaves are quite uneven. What I meant is, the $ORIGIN > splits the zone into some unknown to me syntax/format. Is there anywhere > I can find the description/documentation on it – How exactly slave parse > the zone from master and puts all these arbitrary paragraphs with $ORIGIN. $ORIGIN is simply appended to every name that does not have dot at the end. So $ORIGIN example.com www a 1.2.3.4 and www.example.com. a 1.2.3.4 are completely equivalent. Now, why would you want to look into slave files, except for verifying that the zone transfer succeeded? Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: syntax/format of zone on slave $ORIGIN/paragraph - sorted?
Dnia 2011-02-10 15:49 Walter Smith napisał(a): >Oh - the original thought was to re-shuffle/clean-up zone(s) on Master...and since Slave(s) has this "nice" $ORIGIN paragraphs - would be nice to combine all these unique $ORIGINs back on Master... I personally find only one $ORIGIN at start of zone, and later using only relative names much more readable. >By-the-way --- is there any simple way (WITHOUT modifying named.conf) to "axfr" zone within Master/Slave/loopback? as said before, from slave (And maybe some other hosts, depending what you have in named.conf) dig axfr @master your.zone > your.zone.dump maybe add +noall +answer to get rid of (most) comments and useless stuff. And you will get double SOA record, at start and end of file. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind on vps
root.mydomain.com. ( > 2011011901 ; Serial > 8H ; Refresh > 2H ; Retry > 4W ; Expire > 1D) ; Minimum TTL > @ IN NS ns1.mydomain.com. > @ IN NS ns2.mydomain.com. > 44IN PTR mydomain.com. > 44IN PTR www.mydomain.com. > 45IN PTR virtualdomain.com. > 45IN PTR www.virtualdomain.com. > 44IN PTR ns1.mydomain.com. > 45IN PTR ns2.mydomain.com. First, as stated before, I doubt if anyone will ask your server for that info. Second - what is the name of 11.22.33.44? Is it mydomain.com? www.mydomain.com? ns1.mydomain.com? AFAIK there can be only one PTR record. > > --- end config files - > > In case my configuration is OK, > what must I ask to my vps provider? Probably nothing. If you can dig/nslookup on your host from external hosts, then it looks they don't need to do anything. > what must I do at go daddy? Make sure your primary domain has correctly configured ns names AND IP addresses. I'd advice dig ns mydomain.com @a.gtld-servers.net (or any other name server for your TLD) > At go daddy I added ns1.mydomain.com and ns2.mydomain.com > records and associate them to the two ips in its web > interface. > > At my vps panel I have an option to reverse address domain > names, could it confuse dns? Must I use this registers or > must I leave it blank? I case it is convenient setup a domain > name at VPS dns, what can I put there? Those are the PTR records. For DNS you probably don't need them For email you definitely do, for WWW probably not. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind on vps
On 02/13/11 17:16, Walter Alejandro Iglesias wrote: > On Sun, Feb 13, 2011 at 02:13:48PM +0100, Torinthiel wrote: > >> On 02/13/11 12:52, Walter Alejandro Iglesias wrote: >>> It will be a web hosting sever. I wrote my own web client >>> panel and my own bash scripts to automate the upload of new >>> client's virtual domains. That's why I want to run my own dns >>> server; I want to be able to update the registers in my own >>> machine. >> >> you do know that you should have two SERVERS for your dns? >> Giving two different IPs for your box will work. but is a very bad idea. >> Even if everything else is on that machine, for some uses (eg. mail) >> having no DNS data is worse than having a failed server. > > I read in forums about people that could run their own DNS > server at the same server they had their sites, that's why I > tried. But I know (and I understand why) that the good > practice is to have two external DNS servers in different > locations. It's not only good practice, it's a requirement per RFC103[45]. You'll go by with two IPs for one machine, and if it's only HTTP there won't be enough difference if this machine fails. However you could also consider looking for some other DNS services. Some ISPs provide secondary for free, there might also be a free DNS service somewhere. Or you could find someone in similar situation as you and be secondary for each other. > >>> Reverse zone >>> >>> ; 11.22.33 >>> $TTL86400 >>> @ IN SOA ns1.mydomain.com. root.mydomain.com. ( >>> 2011011901 ; Serial >>> 8H ; Refresh >>> 2H ; Retry >>> 4W ; Expire >>> 1D) ; Minimum TTL >>> @ IN NS ns1.mydomain.com. >>> @ IN NS ns2.mydomain.com. >>> 44 IN PTR mydomain.com. >>> 44 IN PTR www.mydomain.com. >>> 45 IN PTR virtualdomain.com. >>> 45 IN PTR www.virtualdomain.com. >>> 44 IN PTR ns1.mydomain.com. >>> 45 IN PTR ns2.mydomain.com. >> >> >> First, as stated before, I doubt if anyone will ask your server for that >> info. > > Stop here, this is my obscure point: how do you get that your > dns be asked? What do you need? What must I ask to my isp > (my vps provider in this case) for? What do you mean by "to be > designated nameserver for the IPs"? Generally (not only for reverse DNS) you need one thing: delegation. That is, the parent zone (this being .com for mydomain.com and 22.11.in-addr.arpa here) needs to answer 'I don't know about mydomain.com, ask ns.mydomain.com'. And that's the part your server has nothing to say yet, as it happens before query reaches your server. Usually (that being the three places I know personally ;) the place where you register your domain has some kind of web panel where you can either setup the zone (if you use their nameservers) and/or enter the nameservers you want to handle queries. And that's the part you want to do. Now, specific about this part: first, disclaimer: I've never administrated any reverse zones. But still, probably your ISP/VPS provider would be the place to ask. Try doing dig -x 11.22.33.44, and if it returns anything, then you have reverse set up. Maybe some web panel from your ISP allows you to change that to anything else, and maybe you even need it. But if you are doing only HTTP and DNS than anything would be fine, as long as it resolves to anything, and resolves back to you (so if you do dig -x 11.22.33.44 and then dig what-you-got-from-previous you end with 11.22.33.44). IMHO you don't need to handle any in-addr.arpa zone at all, your ISP does it for you. You could change what it resolves to, via a web interface and/or email directly to them,but chances are you don't need it. >> Second - what is the name of 11.22.33.44? Is it mydomain.com? >> www.mydomain.com? ns1.mydomain.com? AFAIK there can be only one PTR record. >> > > Yes, I release of my mistake. Just one domain for ip. > >>> In case my configuration is OK, >>> what must I ask to my vps provider? >> >> Probably nothing. If you can dig/nslookup on your host from external >> hosts, then it looks they don't need to do anything. >> > > This is exactly what a cannot do: to dig/nslookup from > external hosts. Not exactly. You've stated
Re: multi-master with mysql backend
Dnia 2011-02-14 15:52 Mike Mitchell napisał(a): >I'd keep two copies of the BIND config, one that has all the zones as "master", and one that has all the zones as "slave". When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the "master" config, and now you have a new master. > >Before the broken master comes back online, swap out its config with the "slave" config. > >No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Nice idea. I'd go even further - why keep two configs? Have a file with your list of zones, and two scripts that generate either master or slave config. Now you are keeping one common config on both severs, which changes only when you add/remove a zone, and two scripts which are almost identical, except for one line (master address). This should be easier to maintain. Now, just in case, you could put on startup scripts the one that generates slave config, so if it reboots you don't have two master servers. And you could cook up a more complicated script, that tries to ping the other server and runs master config generation, freeze, soa change, thaw, reload and send you an email - and you have fully automated HA. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Please Help
On 02/16/11 23:24, Xiaoxu Huang wrote: > From couple of our DNS servers, we are failed to get correct DNS answer > like followings: > > 1) From server A > # nslookup > Default Server: localhost > Address: 127.0.0.1 > > www.nyc.gov > Server: localhost > Address: 127.0.0.1 > *** localhost can't find www.nyc.gov: Non-existent host/domain#nslookup > > 2) From server B: > # nslookup > > www.nyc.gov > ;; connection timed out; no servers could be reached > > 3) Both servers run bind-9.7.2-P2 And your configuration is? (both named.conf and network topology) Try (from both servers) a) dig @127.0.0.1 b) ping 198.41.0.4 (which is a.root-servers.net's IP address) Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about some oddities in the logs
On 02/22/11 01:41, Eivind Olsen wrote:
> Hello. I've recently put into production a new recursive nameserver, and
> decided to take a look in the logfiles (the old servers didn't have
> logging enabled so I can't really compare the current logs with whatever
> the old ones would have been).
> I understand most of the entries in the logs + statistics, but there's a
> couple of things I'm not sure about - my hope is that someone here can
> shed some light on these, and perhaps also tell me if it's expected to see
> these in the wild.
>
> The nameserver is running BIND 9.7.2-P3 btw, and yes I know 9.7.3 is out -
> it will be upgraded soon.
>
> We're not talking about query logging btw, only a fairly simple logging
> channel:
>
> channel default_debug {
> file "logs/named.run" versions 20 size 500m;
> print-time yes;
> print-category yes;
> print-severity yes;
> severity dynamic;
> };
>
> Now, to the log entries (I've removed timestamps + IP-addresses):
>
> 1) notify: notice: client x.x.x.x#n: notify question section contains no
SOA
> Should I be seeing these normally? They only seem to make up a small part
> of the full logfiles, still seeing a couple of thousand of these in just a
> few days time.
Hmm, looks to me as the box listed as client sends some strange notify
messages. Notify normally should contain SOA, so that receiving NS can
tell if it has outdated zone or no. These don't. What (regarding DNS of
course) is on those machines?
> 2) security: info: client x.x.x.x#n: query (cache) './A/CH' denied
> Not many of these either, but they still seemed a bit weird. Could they be
> caused somehow by me running a slave of the root "." defined as:
> zone "." IN {
> type slave;
> file "slave/root.zone";
> masters {
> ...a couple of the root-servers.net servers
> };
> notify no;
> };
> I wouldn't expect that to be the cause though, as it's defined as class IN
> and not CH.
asking for CH TXT version.bind returns bind's version, unless configured
not to do so. Maybe something also asks for A, but I dunno why. Are
these addresses in your network? Then you can tracethem down probably.
Now, the more important part - why would you be running a slave of root?
AFAIK the root servers don't a) allow transfer b) send you notifies, so
you'll be in trouble as soon as anything changes, which means every week
right now, that root is signed. Why is
zone "." in { type hint; }
not enough for you?
Regards,
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind and IPV6
Dnia 2011-02-22 22:16 Mark Andrews napisał(a): >In message , hugo hugoo writes: >> Dear all, >> >> In the scope of the IPV6 deployment, I have been asked if oiyr DNS server >> s are IPV6 compliant. >> We are now upgrading all our servers to bind-9.6-ESV-R3. >> >> - Can anybody give some feedback on the IPV6 compliancy? >>IS bind-9.6-ESV-R3 totally compliant with IPV6? > >Yes. But a different issue might be is your system (the box Bind runs on, network, routers, firewalls) IPv6 compliant. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: mx selection order
Dnia 2011-02-22 20:29 Terry. napisał(a): >Hello, > >Given I have these MX records: > >example.com.3600IN MX 10 m1.example.com. >example.com.3600IN MX 10 m2.example.com. >example.com.3600IN MX 20 m3.example.com. > > >My question is, when m1.example.com is failed to communicate with, the >remote MTA will continue to talk to m2 or m3? From the beginning: MTA should randomly try m1 or m2, if it fails then the other one, and if both fail than m3. algorithm is simple: try random one from amongst ones with lowest precedence, discarding those failed. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about some oddities in the logs
Dnia 2011-02-22 13:29 Eivind Olsen napisał(a):
>On Tue, 22 Feb 2011 08:59:51 +0100, "Torinthiel"
>wrote:
>> Hmm, looks to me as the box listed as client sends some strange notify
>> messages. Notify normally should contain SOA, so that receiving NS can
>> tell if it has outdated zone or no. These don't. What (regarding DNS of
>> course) is on those machines?
>
>These come from a variety of IP-addresses, belonging to customers
>(we're an ISP). So I don't know what's really on the customers machines.
If your clients should send you notify messages (e.g. you host their
secondary DNS, while they have the primary), and if there are no other
symptoms of malfunction, I'd ignore it. they have no reason to send you
notifies, then maybe you can ask them why are they sending it in the first
place (assuming there's someone worth talking to). But still, I think it's
safe to ignore.
>> asking for CH TXT version.bind returns bind's version, unless configured
>> not to do so. Maybe something also asks for A, but I dunno why. Are
>> these addresses in your network? Then you can tracethem down probably.
>
>These are again from customers addresses.
I'd ignore it. If someone thinks otherwise, please step up.
>
>> Now, the more important part - why would you be running a slave of root?
>> AFAIK the root servers don't a) allow transfer b) send you notifies, so
>> you'll be in trouble as soon as anything changes, which means every week
>> right now, that root is signed. Why is
>> zone "." in { type hint; }
>> not enough for you?
>
>At least some of the root servers allow transfers. They won't send me
>notifies, true. But I don't need that. Currently the root zone has a
>refresh value of 1800 seconds and expire = 604800 seconds, so my slave
>servers will check the root for updates often enough.
>One advantage is that we can now instantly reject queries for things
>like "eivind.local." instantly without having to ask the root servers
>where "local." is served.
Do these happen often enough to warrant such a setup? Ok, it looks it will
work, but you are trading a few (asuming few such TLDs) *possible* queries
per day, for a full zone transfer every few days.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Help on recursive set up
Dnia 2011-02-23 17:59 rams napisał(a): >Hi, >Could you please tell me how to set up for recursive server for NS >delegation records. I know what a recursive nameserver is. I know what NS delegation record is. I have no idea what a recursive nameserver for NS delegation records is. Recursive nameservers/resolvers by definition deal with delegation records, so either you're stating the obvious or missed some critical piece of information. In the first case, just use named.conf from distribution examples, IIRC there was a simple recursive example somewhere, maybe even the default named.conf has related config (and/or comments). Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: why dig +short for NS doesn't get the result
On 03/01/11 04:55, terry wrote: > server1:/var/cache/bind# dig ox.test.nsbeta.info ns @localhost +short > > # got nothing here > > > server1:/var/cache/bind# dig ox.test.nsbeta.info ns @localhost > > ; <<>> DiG 9.6-ESV-R3 <<>> ox.test.nsbeta.info ns @localhost > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53460 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;ox.test.nsbeta.info. IN NS > > ;; AUTHORITY SECTION: > ox.test.nsbeta.info.20222 IN NS dwdns1.nsbeta.info. Look where the answer is > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Tue Mar 1 11:51:21 2011 > ;; MSG SIZE rcvd: 58 > > > I have setup the NS for ox.test.nsbeta.info zone, why dig +short gets > nothing but dig does get the result? +short instructs dig to only write extract of ANSWER section. your reply is in authorative section. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
On 03/01/11 20:17, fakessh @ wrote: > is the repeat isc dlv seems to accept the flag DS > in my case i have to a file dsset-fakessh.eu > but the file contains two keys DS and i don't know which to use The DS you have are both for the same key, only one is SHA1 and other SHA256. You could try any of them, but see below. ISC DLV accepts keys, you have to create an account, add your zone and keys for it. I remember having some trouble trying to add DS records, but DNSKEY worked fine. Of course the zone has to be signed using that key, and ISC asks you to add a TXT record at dlv.your.zone (or something similar) to prove your ability to modify the zone. The procedure is simple and well defined. And about OVH - I don't know if it's related, but I've asked Polish OVH how about providing DNSSEC, as .pl is planned to be signed mid-year, and they've answered me they will probably be ready. This might, or might not be related to providing DNSSEC by other OVH branches and for other registries. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
On 03/01/11 21:52, fakessh @ wrote: > as I now know what key DS uses. That would be the key with id 47103 in your case. The one that has SEP flag, the one that only signs DNSKEY records and not others. Regards, Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Having trouble with logging syntax
Dnia 2011-03-03 13:30 Nate Homier napisał(a):
>I got my logging setup but named-checkconf is spitting out an error.
>
>$named-checkconf /home/nate/named.conf.local
>/home/nate/named.conf.local:11: missing ';' before '3'
>/home/nate/named.conf.local:11: unknown option '3'
>
>I'm pretty sure we don't put an ; after version. I can't see anything
>wrong with my config. All my ; look to be in place. I'm using Ubuntu
>10.04. This is strictly a resolver server on my personal PC at home.
>
>My logging setup.
>
>logging {
>channel query.log {
>file "/var/log/query.log" version; 3 size 5m;
that would by file "/var/log/query.log" version 3 size 5m;
You want 3 versions, so why separate keyword from its parameter?
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
Dnia 2011-03-04 23:07 terry napisał(a): >> Look at RA and RD. If the server recurses, you will get a answer. >> If the server does not recurse, you will get a referral. Then there >> are the really old broken servers which get this wrong. >> > >Hi Mark, > >Please see this for details: > >$ dig nsbeta.info ns @ns34.domaincontrol.com > >; <<>> DiG 9.4.2-P2.1 <<>> nsbeta.info ns @ns34.domaincontrol.com >;; global options: printcmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41454 >;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 >;; WARNING: recursion requested but not available > >;; QUESTION SECTION: >;nsbeta.info. IN NS > >;; ANSWER SECTION: >nsbeta.info.3600IN NS ns34.domaincontrol.com. >nsbeta.info.3600IN NS ns33.domaincontrol.com. > > >There isn't the "ra" flag in the response, why the nameserver has been >also answering with the "ANSWER SECTION"? I think it should answer >with the "AUTHORITY SECTION". But in this case, you're asking the authotrative server. Authorative server answers in answer section, as it knows the answer. Authorative section is for 'I don't know, ask ...' The rule above goes for servers which are not authorative for a given zone. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: About name servers registration
Dnia 2011-03-10 09:53 terry napisał(a): >Hello, > >How do I know that my name servers, ns1.dnsbed.com and >ns2.dnsbed.com, have been registered in ICANN? AFAIK ICANN does not run .com registry, VeriSign does. But this doesn't change anything. First, your nameservers will not be registered per se. But your nameservers may be registered as authorative for your domain, which I guess is dnsbed.com And you can check this with dig ns com to get a list of nameservers for .com (or whatever your parent domain is) then pick any, say b.gtld-servers.net and type dig ns dnsbed.com @b.gtld-servers.net which right now returns dns[1-4].registrar-servers.com, so not the ones you've typed. And, as your servers don't answer for dig ns dnsbed.com @ns1.dnsbed.com then I guess my original assumption of your domain has been wrong. Bujt the procedure still is same. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Master ns on internal lan
On 03/20/11 11:13, x_bind-user...@nospam.pz.podzone.net wrote:
> Hi,
>
> I'm trying to figure out how to configure my nameservers so that the
> master can reside on an internal LAN *only* address.
>
> I already have it configured such that the master is (almost) hidden
> while residing on a public IP. So I should present that first:
>
[cut]
>
> As you can see, ns0 isn't quite totally hidden - it shows up in the
> SOA record. I tried using ns1 in the SOA but then ns1/ns2 failed to
> update correctly when the zone file was updated on ns0. I never
> figured that out and don't see it as a big deal from a privacy POV but
> I accept that probably it's not optimally configured.
And solving your main problem will probably solve this as well.
> Now on to my question. ;-)
>
> Ideally I would like to manage the zones on a main internal server,
> which would serve the internal LAN (including an internal-only zone)
> as well as somehow keeping the public slaves up to date. Part reason
> for this is a policy to shift all internal services onto the LAN and
> away from the DMZ.
>
> This is the plan:
>
> main.mydomain.net - Internal LAN only.
>
> ns0.mydomain.net - Gateway/firewall, public IP (ADSL) + internal LAN.
>
> ns1.mydomain.net - Public nameserver.
>
> ns2.mydomain.net - Public nameserver.
>
> main acts as master for ns0 slave. (and serves dns for the lan)
>
> ns0 acts as master for ns1/ns2 slaves. (and serves dns for the dmz)
>
> This is the problem, I cannot see how to configure the SOA and conf
> files such that zone updates will be notified main -> ns0 -> ns1/ns2.
try putting this in config:
on main:
zone "mydomain.net" {
type master;
...
allow-transfer { ns0.mydomain.net; };
also-notify { ns0.mydomain.net; };
}
on ns0:
zone "mydomain.net" {
type slave;
...
allow-notify { main.mydomain.net; };
allow-transfer { ns1.mydomain.net; ns2.mydomain.net; };
also-notify { ns1.mydomain.net; ns2.mydomain.net; }
}
on ns1/2:
zone "mydomain.net" {
type slave;
...
allow-notify { ns0.mydomain.net; };
}
The allow-notify makes slave servers to accept notify messages from
someone that's not listed as master in SOA. Putting this on ns1/2 will
probably solve your first issue, with ns0 not completely hidden.
also-notify makes bind send notify messages to those servers. Probably
also-notify on ns0 is not needed, as ns1/2 are listed in zone as NS. But
on main it will be neeed, as ns0 is not listed as NS for your domain.
If you want to put ns1 at SOA as master, then you'd also need notify no
at ns1 (so it won't send notifies at all), and notify-to-soa yes at ns0
(so it will send notify to ns1).
Oh, and I really hope ns0.mydomain.net has static IP address even though
it has ADSL. If no, you can either use ip/length or (even better) use
TSIG keys as authentication.
Regards,
Torinthiel
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: problem validate key of isc dlv
On 03/20/11 22:33, fakessh @ wrote: > and what do I do. You have to add your key to ISC's DLV registry. Go to dlv.isc.org, create account, login, add a zone, add keys for it and publish a record in your zone validating that you're the owner of the zone. You will be told what to do after you create zone. > and what is this other publication of another DS I have no idea what do you mean by this sentence. Torinthiel > > > Le lundi 21 mars 2011 à 08:25 +1100, Mark Andrews a écrit : >> In message <1300650238.6651.15.camel@localhost.localdomain>, "fakessh @" >> writes >> : >>> hello bind network and duru. >>> >>> I can not validate the key dlv via the website of the isc. >>> I do not understand why the warning is the isc >>> you have an explanation >>> SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR >>> 4.502:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR >>> 4.502:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR >>> 4.502:INFO Total answers: 3 >>> 4.503:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164 >>> 4.504:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232 >>> 4.504:SUCCESS All DNSKEY responses are identical. >>> 4.515:DEBUG VERIFY-DNSKEY: Checking tag=10231 flags=257 alg=RSASHA1 >>> AwEAAbwO...8fkjXphfS8= >>> 4.515:DEBUG VERIFY-DNSKEY: Ignoring key. >>> 4.515:DEBUG VERIFY-DNSKEY: Checking tag=30111 flags=256 alg=RSASHA1 >>> AwEAAb1q...jG+UQeAtYE= >>> 4.515:DEBUG VERIFY-DNSKEY: Ignoring key. >>> 4.515:INFO VERIFY-DNSKEY: 2 DNSKEYs found. >>> 4.515:INFO VERIFY-DNSKEY: 0 keys found after filtering. >>> 4.515:DEBUG VERIFY-DNSKEY: Using keys: >>> 4.516:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY >>> 4.516:FAILURE VERIFY-DNSKEY: No keys found after filtering. >>> 4.516:FAILURE DNSKEY signature did not validate. >>> 4.516:FINAL_FAILURE FAILURE >> >> Based on the key tags and the truncated keys I think these keys are >> for fakessh.eu and if so there isn't a DLV record or a DS published >> for fakessh.eu. The only other thing the validator can check against >> is any installed trust-anchor. >> >> Mark >> >> ; <<>> DiG 9.6.0-APPLE-P2 <<>> fakessh.eu.dlv.isc.org dlv >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48161 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >> >> ; <<>> DiG 9.6.0-APPLE-P2 <<>> fakessh.eu ds >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63623 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >> >> >> >>> -- >>> gpg --keyserver pgp.mit.edu --recv-key 092164A7 >>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 >>> >>> >>> >>> ___ >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem validate key of isc dlv
On 03/21/11 02:13, fakessh @ wrote: > Yes, I bothered to redeploy new keys, fields TXT, a new signature. > and more on a new rehabilitation isc dlv. > > > I still get the same error > > nb : Simply debuggers dnssec still provide all kinds of resultasts And that's probably the main problem. Two of your nameservers have either disabled DNSSec, or don't support it at all: Correct answer: $ dig +dnssec +norecurse +noall +answer dnskey fakessh.eu @r13151.ovh.net. fakessh.eu. 38400 IN DNSKEY 257 3 5 AwEAAbwO9edhHAn00RfAzMEwBdcYK1fnP16vh9BXltHrdAesHRFJ7G0l tT4GyBgQcjFZyfk/HdHpnlDuT8fkjXphfS8= fakessh.eu. 38400 IN DNSKEY 256 3 5 AwEAAb1qeaah5D2pS+IcZiJiyZRA3KTgaV0/Sd8kSfzfbI3X45XZ7aLb tIoN/kLJc2G7qAdqnSmoiN+TojG+UQeAtYE= fakessh.eu. 38400 IN RRSIG DNSKEY 5 2 38400 20110419151040 20110320151040 10231 fakessh.eu. VeCJRPlvC6gr+3f/OuMCrFQR42oQkDxJ7nTfLcJMH2XwPyvBOdR/nv55 ZSs5wJ5Bl5CKAZjMRyWrUtM/wSGdTw== fakessh.eu. 38400 IN RRSIG DNSKEY 5 2 38400 20110419151040 20110320151040 30111 fakessh.eu. Y1DqOwGfRTxNdFruvOSalp8pVy+FWd/G+pqs+Qu4tkkLvanHcTisDSXA JqbKvZpRrwGoL9o+5wKwPisDDqtf6g== And incorrect (note missing RRSIGs): dig +dnssec +noall +answer dnskey fakessh.eu @ns0.xname.org. fakessh.eu. 38400 IN DNSKEY 257 3 5 AwEAAbwO9edhHAn00RfAzMEwBdcYK1fnP16vh9BXltHrdAesHRFJ7G0l tT4GyBgQcjFZyfk/HdHpnlDuT8fkjXphfS8= fakessh.eu. 38400 IN DNSKEY 256 3 5 AwEAAb1qeaah5D2pS+IcZiJiyZRA3KTgaV0/Sd8kSfzfbI3X45XZ7aLb tIoN/kLJc2G7qAdqnSmoiN+TojG+UQeAtYE= dig +dnssec +noall +answer dnskey fakessh.eu @ns2.xname.org. fakessh.eu. 38400 IN DNSKEY 256 3 5 AwEAAb1qeaah5D2pS+IcZiJiyZRA3KTgaV0/Sd8kSfzfbI3X45XZ7aLb tIoN/kLJc2G7qAdqnSmoiN+TojG+UQeAtYEA fakessh.eu. 38400 IN DNSKEY 257 3 5 AwEAAbwO9edhHAn00RfAzMEwBdcYK1fnP16vh9BXltHrdAesHRFJ7G0l tT4GyBgQcjFZyfk/HdHpnlDuT8fkjXphfS8A ISC doesn't publish your DLV record, because it has to see consistent view of your zone. And it doesn't as you have missing RRSIGS from some nameservers. Either convince admins to deploy DNSSec or drop those nameservers. Then it should work. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: gid expected error
On 03/26/11 07:01, Tim Dunphy wrote:
> hello,
>
> a file was apparently modified in our setup and now bind9 refuses to
> start. This is the error message we receive
>
> [root@LBSD2:/etc/namedb/master] #/etc/rc.d/named start
> dev changed
> gid expected 10 found 0 modified
Guessing by this, I'd do ls -ld /dev /dev/{log,null,random,urandom,zero}
Torinthiel
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Error in bind manpage?
I've noticed a probable error in dnssec-signzone's man page. Description for option -T says that "the default is the minimum TTL value from the zone's SOA record". But my tests show, that the default is the TTL of the SOA itself. Which by the way makes much more sense, as minimum/negative TTL is usually much lower than SOA's TTL. Using bind version 9.7.2-P3. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Error in bind manpage?
On 03/27/11 09:07, Mark Andrews wrote: > Could you please send it to bind9-bugs. That way it will be tracked. Thanks for the pointer, did that. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem for validate the script dnssec to isc dlv
On 03/27/11 19:09, fakessh @ wrote: > in insurance I googled > no result > > how to do this ... The procedure is everywhere around the ISC site. See eg. http://www.isc.org/solutions/dlv https://dlv.isc.org/about/using my mail on 3rd jan, 21:00 in reply to yours (thread inconsistency dnssec debuguers response and writing conseil for new areas zone) Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem for validate the script dnssec to isc dlv
On 03/27/11 20:45, fakessh @ wrote: > That would be the key with id 47103 in your case. The one that has SEP > flag, the one that only signs DNSKEY records and not others. > Regards, > Torinthiel > http://www.mail-archive.com/bind-users@lists.isc.org/msg09107.html > > This is your word > > i reread the thread to fevrier > http://www.mail-archive.com/bind-users@lists.isc.org/msg09084.html > > Mark Andrews quote > Because there are already DLV records for the key in the DLV. > > ;; ANSWER SECTION: > fakessh.eu.dlv.isc.org. 3529IN DLV 47103 3 2 > 68096942650C1DD89D5BE43A9EEA05BA9C20F09EDC55309F4F1CD348 4D8ED07B > fakessh.eu.dlv.isc.org. 3529IN DLV 47103 3 1 > CFEA04C5B918359273D6BAC07AE7F2DF5225E357 > > > here i am Ok. Now, reread the current thread. At least three people in this thread only have identified and pinpointed the problem. Two of your nameservers, ns0.xname.org and ns2.xname.org do not support DNSSec right now. Unless you do something about this, possibilities include fixing them or dropping them from your authoritative servers, there's nothing anyone can help you. Your zone is NOT DNSSec enabled, and ISC's DLV registry correctly refuses to list it's keys. If you don't trust us, please go to http://dnsviz.net/d/fakessh.eu/dnssec/ or http://secspider.cs.ucla.edu/fakessh-eu--zone.html, probably your account in dlv.isc.org or any DNSSec debugger of your choice. I've really assumed that you've fixed issues that were pointed numerous times before asking for next steps. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trouble loading a zone file after updating BIND
On 03/31/11 04:54, Mike Diggins wrote: > The A records for the two nameservers exist in the sub.Domain.CA zone > file. I can fix the error by adding the two nameserver A records to the > Domain.CA zone file but I'm wondering why this is an error with 9.7, and > not 9.2.1, and is this the correct way to fix this? Yes, it is the correct way. These are so-called 'glue records' and are needed if (and only if) the nameservers are below the zone apex. If you have one NS below zone apex, and another somewhere outside, than you need one glue record. And these are needed because server needs to know about NS, master because it needs to send notify and other servers (like .CA in your example) to provide correct referrals. Probably in 9.2 it wasn't required, but according to RFC 1034, last paragraph of section 4.2.1, it is correct behaviour to require it. Torinthiek signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9 And Short Name resolution Problem
On 03/31/11 20:58, Barry Finkel wrote:
> On 03/31/11 13:17, bind-users-requ...@lists.isc.org wrote:
>> Hello,
>>
>> I get the following messages on the BIND server when I do a short name
>> nslookup from a client:
>>
>> Mar 31 14:08:04 jedi named[1299]: [ID 873579 daemon.info] network
>> unreachable resolving 'C.ROOT-SERVERS.NET//IN':
>> 2001:500:1::803f:235#53
>> Mar 31 14:08:05 jedi named[1299]: [ID 873579 daemon.info] network
>> unreachable resolving 'I.ROOT-SERVERS.NET//IN':
>> 2001:500:1::803f:235#53
>> Mar 31 14:08:07 jedi named[1299]: [ID 873579 daemon.info] network
>> unreachable resolving 'B.ROOT-SERVERS.NET//IN': 2001:500:2f::f#53
>> Mar 31 14:08:07 jedi named[1299]: [ID 873579 daemon.info] network
>> unreachable resolving 'L.ROOT-SERVERS.NET//IN': 2001:500:2f::f#53
>>
>> The config files are below, we are running BIND 9 on Solaris 10. We
>> currently have 2 domain names configured and on IP address on the BIND
>> server itself. Any ideas from the gurus??
>>
>> Thanks
>
> You do not have IPv6 connectivity from the DNS server to
> {C,I,B,L}.root-servers.net.
And is it possible to make BIND stop trying to use IPv6 at all? I'm in a
similar situation, I know I have connection issues and I simply want
bind to either not use IPv6 or at least prefer IPv4.
liste-on-v6 {none;} in named.conf does not help, and I'm not much
surprised, as it's about listening and not querying.
Torinthiel
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone File IP address/Hostname
On 04/01/11 03:47, Tony MacDoodle wrote:
> Hello,
>
> I am trying to configure 2 different domains on one host that only has
> one physical interface plummed.
>
> I think I have an errorthat I list the hostname of the interface in both
> zone files as below and this might be why I can't resolve properly. Do
> you see any mistakes in the files below?
> The only active interface is 192.168.5.5
and you can't resolve properly from where? From localhost? That's
probably because you've configured BIND to only listen on external
address, not the local one. In this config (listen-on { 192.168.5.5; };)
it won't accept local queries, as these come to 127.0.0.1.
But from other box command
dig rac-scan.rac.local @192.168.5.5 should work.
Are there any relevant messages in logs? What are the error
messages/results when you try to resolve? How you test if resolution works?
Having bind run multiple zones is absolutely normal, and there are no
reasons to require more than one IP address with that.
Torinthiel
>
> root:/var/named# cat named.conf
> options {
> listen-on-v6 { none; };
> listen-on { 192.168.5.5; };
> directory "/var/named";
> };
> zone "0.0.127.in-addr.arpa" {
> type master;
> file "db.127.0.0";
> };
> zone "rac.local" {
> type master;
> file "db.rac";
> };
> zone "rac2.local" {
> type master;
> file "db.rac2";
> };
> zone "10.168.192.in-addr.arpa" {
> type master;
> file "db.192.168.10";
> };
> zone "20.168.192.in-addr.arpa" {
> type master;
> file "db.192.168.20";
> };
>
> root:jedi:/var/named# cat db.rac
> $TTL 86400
> @ SOA jedi root ( 2 10800 3600 604800 600 )
> NS jedi
> localhost A 127.0.0.1
> rac-scanA xxx.xxx.xxx.xxx
> A xxx.xxx.xxx.xxx
> A xxx.xxx.xxx.xxx
> MX 10 rac-scan
>
> root:jedi:/var/named# cat db.rac2
> $TTL 86400
> @ SOA jedi root ( 3 10800 3600 604800 600 )
> NS jedi
> localhost A 127.0.0.1
> rac2-scan A xxx.xxx.xxx.xxx
> A xxx.xxx.xxx.xxx
> A xxx.xxx.xxx.xxx
> MX 10 rac2-scan
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Change Query Type on nslookup
On 04/07/11 06:42, mee thun wrote: > Good Morning.. > > I am new member in this mailing list. I need help to change the query > type in the nslookup command. > The default nslookup using A, but I use ipv6 so the query type must use > . I don't know how to change the default nslookup from A to > permanently? first, this is a bind list, and nslookup is not a bind tool. Consider using dig, which is much better in this case. And, IIRC, when you run nslookup you can put set type= yourquery.com and that should give the effect you want I have no idea how to change the default query type for any of the tools. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS queries with 3 networks
Dnia 2011-04-08 09:11 Flex Banana napisał(a): >hello floks, > >i have a DNS server running bind-9.7.3 on a linux box, 3 differents networks connected to 3 ethernet cards: > >eth0: 192.168.1.1/24 >eth1: 172.16.1.1/24 >eth2: 10.140.27.1/24 > >i would like to have the same DNS resolving the good address from the good network, example: > >from the 192.168.1.1/24 network: host mydns.example.com = >192.168.1.10 >from the 172.16.1.1/24 network:host mydns.example.com = >172.16.1.10 >from the 10.140.27.1/24 network: host mydns.example.com = >10.140.27.10 The only way would be to create 3 different zone files, with those addresses, and 3 different views on this sever, each having a different zone file and configured for different networks I don't have bind ARM on-hand, but there was a section on views. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
Dnia 2011-04-08 21:58 Patrick Rynhart napisał(a):
>I am new to using BIND and thought that I would start by setting up a
>caching-only name server on a VM running CentOS 5.5. While in this
>mode, my understanding is that named should be passively listening for
>any DNS requests that are resolved and be adding them to its local DB.
>
>Adding localhost to /etc/resolv.conf shouldn't be necessary in order for
>entries to be added to the DB but obviously required if you want to make
>use of the DNS caching.
>
>What I'm observing is that any DNS requests that are resolved aren't
>being added to the DB - i.e. the result of "rndc dumpdb" is always
>empty. My named.conf file is as posted inline below; this is a vanilla
>named.caching-nameserver.conf (as packaged by CentOS) aside from my
>adding the VMWare subnet 192.168.239.0/24 which my VM is on. I also
>post the output of "named -g" along with named.local below.
You say you successfully perform queries on that box. How are you doing
this?
dig something @localhost
dig something
ping something
Last two might not work, as it asks resolver for that box, which is
configured in resolv.conf and might not be localhost
The first is guaranteed to ask this bind.
Also, see below for remarks on your configuration.
>named.conf
>--
>
>options {
>listen-on port 53 { 127.0.0.1; 192.168.239.0/24; };
192.168.239.0 should be a single address, not a range. It's address bind
listens on, not the one it can receive queries from.
>//listen-on-v6 port 53 { ::1; };
>directory "/var/named";
>dump-file "/var/named/data/cache_dump.db";
>statistics-file "/var/named/data/named_stats.txt";
>memstatistics-file "/var/named/data/named_mem_stats.txt";
>
>// Those options should be used carefully because they
>// disable port randomization
>query-sourceport 53;
>query-source-v6 port 53;
>
>allow-query { localhost; 192.168.239.0/24; };
>allow-query-cache { localhost; 192.168.239.0/24; };
>};
>logging {
>channel default_debug {
>file "data/named.run";
>severity dynamic;
>};
>};
>view localhost_resolver {
>match-clients { localhost; 192.168.239.0/24;};
>match-destinations { localhost; 192.168.239.0/24;};
>recursion yes;
>include "/etc/named.rfc1912.zones";
>};
You are sure you need view? This one here doesn't seem to add anything , and
it does seem strange.
You specify here, that clients from your local IP subnet, that ask for names
in your local IP subnet can ask recursive queries, and have some pretty
standard zones.
My quess would be that it won't require recursive queries. And if you want
to limit who can use your server recursively,
its better to use option {allow-recursion{ 192.168.239.0/24;};}
Regards,
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
Dnia 2011-04-08 23:00 Patrick Rynhart napisał(a): >On 8/04/2011 10:11 p.m., Tony Finch wrote: > >> No, only DNS requests that are handled by the server itself are cached. >> There is no sniffing going on. >> >> Tony. > >Thank you for the clarification. If I add "nameserver 127.0.0.1" to the >VM (and comment out the existing name servers) and attempt to resolve a >DNS entry, the I see output similar to the following: > >08-Apr-2011 22:51:50.116 network unreachable resolving >'www.redhat.com/A/IN': 2001:500:2f::f#53 >08-Apr-2011 22:51:54.023 network unreachable resolving >'www.redhat.com/A/IN': 2001:503:c27::2:30#53 >08-Apr-2011 22:51:54.024 network unreachable resolving './NS/IN': >2001:503:c27::2:30#53 > >I understand that this is because there is no upstream DNS for BIND as >configured in my named.conf. However, if I try to add a forward It might be, but it also might be because you have no IPv6 connectivity. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS record delegation
On 04/10/11 20:42, Parashar Singh wrote: > We want to be able to point the wild card (*.domain.com > <http://domain.com>) and the root domain (domain.com > <http://domain.com>) to the GLB’s while not breaking the other custom > prefixes within that domain’s record (stage.domain.com > <http://stage.domain.com>, foo.domain.com <http://foo.domain.com>, etc.). > Except some 10-20 A records, as declared in zone file, for all other DNS > lookup request shall be forwarded to Global Load Balancer. > Allow any records on the DNS server to resolve to the respective records > on DNS. > All other records are captured by the wildcard and load balanced. > The load balancers will forward the queries to the Apache web servers > which will direct users to the appropriate website. > > Can you suggest, how we can configure BIND to do above setup. if you type *.domain.com. IN A 1.2.3.4 in your zone file, bind interprets this as "every record that is not configured otherwise should get a record of type A and value 1.2.3.4" So, if I understand correctly what you want to do, just specify normal A records for special domains and root domain as well, and add the wildcard record. For this example assume 1.2.3.4 is IP of GLB, and 4.3.2.1 is IP of machine serving other stuff. So the following zone fragment should work $ORIGIN domain.com. @ SOA (...) @ NS ... @ A 1.2.3.4 stage A 4.3.2.1 foo A 4.3.2.1 * A 1.2.3.4 END FRAGMENT of course stage and foo can have different IP addresses, and you probably want to add MX and other records as well. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Migrate domains to different DNS servers
Dnia 2011-04-20 17:25 listus...@gmail.com napisał(a): >Hello all, > >We have a couple of BIND 8 DNS servers that we want to decommission, >obviously we need to migrate the domains to other DNS servers first, which >ordinarily involves zone transfer and domain re-delegation. However, we do >not have control over a lot of the domains (think hundreds) on the BIND 8 >servers, meaning we cannot re-delegate. In what sense you don't have control? I assume you don't have administrative access to the BIND8 boxes. Do you have AXFR access to BIND8 boxes and/or do you have the zone files? Do you have access to registrar, where you have registered your domains? Also, important factor is whether the DNS for those domains are in-zone or out-zone i.e. assume you have example.com. Are NS servers ns1.example.com (in-zone) or ns1.otherdomain.com (out-zone) One important problem is data. If you don't have access to zones' contents (either via AXFR or having zone files) then how would you know what your new nameservers should respond? Assuming you have data, here are your options for delegation If you have access to registrar, you can freely change the servers domain is delegated to, so you can simply change that delegation. i.e. domain was delegated to ns1.domain.com, now is to ns3.domain.com or ns1.newdomain.com In case of out-zone nameservers that's only a name change. In case of in-zone nameservers, it's either name and IP address change, or only IP address change. If you don't have registrar access, you have out-zone nameservers and you control (can change RR in) the zone that nameservers are, you can change the A/ records for NS, which will be a variation of your idea. If you don't have registrar access and either you have in-zone nameservers, or can't control A/ records of out-zone nameservers, than AFAIK you're out of luck. >A desperate measure (if you want to call it) is to transfer the zones to the >new DNS infrastructure then change the A record of the old DNS to use the IP >address of the new DNS. Effectively the old DNS becomes an alias of the new >DNS. Possible problem: glue records. With internal NS and no access to registrar you have no way to update glue records, so domain will still be delegated to old servers. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: the valid content of TXT RR
On 04/22/11 04:49, Doug wrote: > 2011/4/21 Mark Andrews : >> >> In message , Doug writes: >>> Hello, >>> >>> what characters can or can't be included in a TXT record for DNS? >>> >>> Thanks. >> >> Named supports 8 bit data using the same presentation encoding as domain >> names. >> > > > Thanks mark. > But I meant what text string is permitted or not permitted in a TXT record. There are no specific constraints on TXT record. It's free form text, so you can specify 'blalasurawer vwa3ku4rygwli avwiruy' as well as 'do not use' or spf syntax or anything. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: shared KSK for static zone and dynamic subzone?
On 04/27/11 05:40, /dev/rob0 wrote: > On Tue, Apr 26, 2011 at 10:15:18AM +0100, Phil Mayers wrote: >> On 04/26/2011 02:13 AM, /dev/rob0 wrote: >>> Is there any >>> reason why I can't use the parent zone's KSK for the dynamic >>> zone? Better yet, is there a reason why I shouldn't? >> >> Better yet, why *would* you? Keys aren't exactly expensive to >> generate. > > Again, the $SUBJECT problem is resolved, but I have come upon a > possible reason to reuse a key. > > I'm setting up a private namespace (RFC 1918 networks and imaginary > domain names) named+dhcpd system with three static zones, a dynamic > forward zone, and two dynamic reverse zones. Six total. > > I want all these zones to be signed. Why? No good reason, just a > learning exercise, actually. "Because I can." That's a very good reason. > [...] > > So that's what I'm going to do. Two more zones, four more keys, but > only two in trusted-keys. Tolerable. You have some other options as well. First, as you've noticed, only the top zone in the chain needs to have keys configured, all zones below can benefit from DS records. Second, if your zones are public, you can add your key to dlv.isc.org, and only have to configure one key (which is build in into bind BTW). Third, you can create your own DLV, and still use one key even with private zones. Downside is that BIND cannot use two DLV repositories, so you won't benefit from a lot of DLV configured zones. And I don't know of a sensible way to duplicate ISC DLV and add some more keys. You could download zones from http://secspider.cs.ucla.edu/ add your own keys and sign by your own key. But keep in mind, that while ISC DLV asks admins to configure their zones and verifies that they have keys and abilities to modify zone, secspider simply walks everything (but from several points around the world), so it's probably less secure. > >> Anyway, the answer is "not really". The keys that bind generates >> include the zone name, and you can't easily use a key whose name >> != zone, and certainly not whose name is in a different zone. >> >> You're just complicating your life to no benefit. Use a different >> key for the child. > > I'm a bit late to the DNSSEC party, what with the signed root being > in place already, but ISTM that these trusted-keys could be a major > management problem. Am I wrong? Is it still a problem? Yes, but there are several possibilities to solve it. First note that root is already signed, but not all (not even most) TLDs are signed/accept DS records for delegations. So eg in .pl you are no better than if root was not signed. Ways to circumvent this include: 1) have your key distributed widely. Worst IMHO option, as it requires a good distribution chain both at start, and when you change your KSK. 2) DLV - from DNS point of view it's a simple zone with a bit different record types. If you have dlv.net, and want to check if example.com is correclty signed, than your resolver asks for example.com.dlv.net, of type DLV and if it receives correct answer (this implies that first you trust DLV's key) it behaves just as if it got example.com's DS record from .com. You still have to maintain key, but only one. 3) RFC 5011 specifies how keys can authenticate themselves, thus simplifying KSK rollover. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Panic Time! Key Generation Question
On 04/27/11 07:52, Martin McCormick wrote: > I changed our tsig key and broke the world. Actually, the DNS's > are happy. DHCP appears to be happy, but I am generating bad > keys. > > I wrote a script as follows: > > #! /bin/sh > /usr/local/sbin/dnssec-keygen -a hmac-md5 -b 512 -n HOST keyname > > It produced a beautiful-looking key that bind was happy with in > named.conf. Rndc worked after changing it there so I installed > it in our production DNS's. > > Then the fun started. I put it in dhcpd and it broke > because there was at least one blank in the string. > > After googling a bit, I used all after the blank. This > made bind happy, still and dhcp worked but the original key no > longer works so we can't do any manual dynamic updates until I > install a key that actually works. > > Everything I read says to generate the key in pretty > much this manner so how can I get one that works everywhere > without white spaces that will blow up dhcpd? > > I guess I was lucky before that there wre no spaces in the > previous key. Try deleting the space. Just this. dnssec-keygen inserts space for readability purposes only. If you still have original *.key and *.private files, you can check it yourself, that the Key field in *private contains exactly the same as *.key, minus the space. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR/IN' denied
On 04/28/11 05:10, jeffrey j donovan wrote:
> Greetings
>
> I have 2 systems master and slave, the slave seems to not allow the zone
> transfer.
It's the master that doesn't allow zone transfer. You have
allow-transfer and allow-update in mydomain.com (which I guess is
transfering correctly, at least nothing you've written says otherwise),
but you don't have these in reverse zones.
Torinthiel
>
> master 192.168.1.2
>
> //
> // mydomain.com
>
> zone "mydomain.com" {
> type master;
> file "domain.db";
> allow-transfer { 192.168.96.3; };
> allow-update {none;};
> };
>
> zone "96.168.192.in-addr.arpa" {
> type master;
> file "in-arpa-192/REV-NOC.db";
> };
>
> zone "97.168.192.in-addr.arpa" {
> type master;
> file "in-arpa-192/REV-EDC.db";
> };
>
>
> slave; 192.168.1.3
>
> //
> // mydomain.com
>
> zone "mydomain.com" {
> type slave;
> masters { 192.168.96.2; };
> file "domain.db";
> allow-transfer {none;};
> };
>
> zone "96.168.192.in-addr.arpa" {
> type slave;
> masters { 192.168.96.2; };
> file "in-arpa-209/REV-NOC.db";
> };
>
> zone "97.168.192.in-addr.arpa" {
> type slave;
> masters { 209.96.96.2; };
> file "in-arpa-209/REV-EDC.db";
> };
>
>
> here is the log output
>
> from master
> -Apr-2011 22:54:17.539 security: error: client 192.168.96.3#60712: view
> com.basd.DNS.public: zone transfer '96.168.192.in-addr.arpa/AXFR/IN' denied
> -Apr-2011 22:54:17.539 security: error: client 192.168.96.3#60737: view
> com.basd.DNS.public: zone transfer '97.168.192.in-addr.arpa/AXFR/IN' denied
>
> from slave
>
>
> 27-Apr-2011 22:57:23.039 general: info: zone
> 96.168.192.in-addr.arpa/IN/com.basd.DNS.public: Transfer started.
> 27-Apr-2011 22:57:23.041 xfer-in: info: transfer of
> '96.168.192.in-addr.arpa/IN/com.basd.DNS.public' from 192.168.96.2#53:
> connected using 192.168.96.3#60755
> 27-Apr-2011 22:57:23.042 xfer-in: error: transfer of
> '96.168.192.in-addr.arpa/IN/com.basd.DNS.public' from 192.168.96.2#53: failed
> while receiving responses: REFUSED
> 27-Apr-2011 22:57:23.042 xfer-in: info: transfer of
> '96.168.192.in-addr.arpa/IN/com.basd.DNS.public' from 192.168.96.2#53:
> Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
>
>
> firewall on the slave is off and the master has an allow statement for dns
> 12310271101096192 allow tcp from any to any dst-port 53
> 12310 2124656 168384287 allow udp from any to any dst-port 53
>
>
> not sure what I missed , any insight would be helpful
>
> -j
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: does authority named require the external name servers?
On 05/02/11 09:16, Jeff Pang wrote: > When I run the authority named on a linux/unix like system, but don't > put the reachable public nameservers on /etc/resolv.conf. > What will happen to the authority named? Will it work right? Authority named never sends queries on it's own, only responds to submitted queries. So it will work correctly, although you won't be able to resolve anything from that box. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: does authority named require the external name servers?
On 05/02/11 14:20, Jeff Pang wrote: > 2011/5/2 Jeff Pang : >> 2011/5/2 Torinthiel : >> >>> Authority named never sends queries on it's own, only responds to >>> submitted queries. >> Doesn't it execute iterative query from the root server? >> >> For example, given the nameserver is authority for abc.com. >> And abc.com has two NS RRs: >> >> abc.com.IN NS ns1.def.com. >> abc.com.IN NS ns2.def.com. >> >> def.com is authoritative resolved by other nameservers. >> >> If there is no correct nameserver list in /etc/resolv.conf, then this >> named can't find ns1.def.com and ns2.def.com? >> As you've noticed below, named will be able to find it. But why should it? First, if it's authorative for abc.com than it's probably one of ns[12].def.com, and second, a response with only nameservers and without their addresses is perfectly valid response. And not that unusual too. BIND will not add glue records for nameservers in zones which it's not authorative for. So in this example if said server is also authorative for def.com, than it knows ns[12].def.com addresses without querying root servers. If it is not, it won't add glue records no matter what. > I think BIND will always have the ability to find all domain-names > regardless there is valid entires in /etc/resolv.conf or not, since > BIND has the ability to execute iterative query from the root server, > and root server list is built-in. BIND will be. Rest of the system won't. Unless you ocnfigure BIND to resolve recursive queries from localhost and put it in /etc/resolv.conf signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC submit of DLV vs DNSKEY records?
On 05/05/11 22:47, dchilton+b...@bestmail.us wrote: > "missed it by THAT much ...". thx! relocating to bind-users. > > On Thu, 05 May 2011 14:37 -0500, "/dev/rob0" wrote: >> FWIW I think you hit the wrong list. Did you mean bind-users@isc? > > >> On Thu, May 05, 2011 at 12:25:27PM -0700, dchilton+b...@bestmail.us >>wrote: >>> after signing my zones with 'dnssec-signzone', i 've got both >>> >>> dsset-domain.com >>> dlvset-domain.com >>> >>> containing DS- and DLV-records, respectively. >>> >>> i know i *can* submit the records to my registrar (DS records) >>> and dlv.isc.org (DLV records), but should I do both? >>> >>> i'm not clear if these are redundant mechs for getting to a >>> 'valid' DNSSEC state, or complementary. >>> >>> can anyone clarify -- both or just one? and if just one, which >>> one? >> >> [I hope someone will correct me if I'm wrong.] >> >> My understanding: if the parent is signed, that is the only way a >> child zone can be validated, unless of course using trusted-keys. >> DLV is only done when the parent is unsigned. DLV can be done anyway, but having a signed parent is better. Consider this situation: you have signed parent, but not a chain to root (i.e. an island of trust). This makes your zone unvalidabe to anyone that doesn't trust that island. now, if you have a DLV record, than anyone trusting it can also validate your zone. If, OTOH, one trusts parent, then why should he bother checking DLV? Having a signed parent won't stop anyone from lookng at DLV (signed != trusted). Anyway, .com is now signed and if you can put DS in .com than putting it in DLV as well is overkill. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Compromised BIND?
On 05/31/11 20:38, Supersonic wrote: > I have a BIND 9.8.0-P2 server instance running on a production server. > My firewall is showing repeated attempts by named.exe to connect to IP > addresses in foreign countries on ports , 6667 and 6669 - common IRC > ports used by worms/trojans/zombies. Checking my named.exe file, it > shows that it is unchanged from the installation source. Is this > connection normal? Should I be allowing it? Looks bad. Guessing by named.exe you're running windows. Try checking if it's the same named.exe that you think - I've seen worms disguising themselves as same name only different folder, or as "named .exe" with space appended to base name. Looks great if you have hidded extensions, as it seems you have two files with name "named". Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS is tainted
On 06/08/11 05:09, Jeff Peng wrote: > Hello, > >>From the dig info below: > > C:\dig>dig +nocmd www.nsbeta.info +noall +answer @ns1.google.com > www.nsbeta.info.3497IN CNAME nsbeta.info. > nsbeta.info.2434IN A 74.117.232.204 > > C:\dig>dig +nocmd www.nsbeta.info +noall +answer @ns1.google.com > www.nsbeta.info.3492IN CNAME nsbeta.info. > nsbeta.info.2429IN A 74.117.232.204 > > C:\dig>dig +nocmd www.nsbeta.info +noall +answer @ns1.google.com > www.nsbeta.info.3486IN CNAME nsbeta.info. > nsbeta.info.2423IN A 74.117.232.204 > > > I think my office network's DNS is tainted. because: What do you mean by 'your office DNS' if you're not asking anything in your office? It looks rather like either someone in your office or your ISP is intercepting DNS traffic and answering questions directly. Probably dig without server would result in answers fitting in same decreasing TTL. This is bad, but I don't think you can do much to avoid it, except complaining or creating some VPN tunnel. It's not however too bad, unless you're either using TSIG and have locally configured keys, or trying to debug some specific DNS problem. Answers go out and are returned, that's most of what's expected from DNS. Torinthiel > > 1) ns1.google.com is authoritative nameserver only, which shouldn't answer > this query. > 2) the TTL is decreased each time, if it's a real authority answer, the TTL > should be all the same. > > And this is the full output of dig: > > C:\dig>dig www.nsbeta.info @ns1.google.com > > ; <<>> DiG 9.3.2 <<>> www.nsbeta.info @ns1.google.com > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1183 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.nsbeta.info. IN A > > ;; ANSWER SECTION: > www.nsbeta.info.3111IN CNAME nsbeta.info. > nsbeta.info.2048IN A 74.117.232.204 > > ;; Query time: 15 msec > ;; SERVER: 216.239.32.10#53(216.239.32.10) > ;; WHEN: Wed Jun 08 11:09:09 2011 > ;; MSG SIZE rcvd: 74 > > > How to deal with this case? Thanks. > > Regards. > > > FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! > Check it out at http://www.inbox.com/earth > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: second nameserver with two IPs
On 06/08/11 03:37, Jeff Peng wrote: > Hello, > > My second nameserver has tow IPs, for example, > > 61.144.56.1 > 61.144.57.1 > (They are in different CIDRs.) > > and my ns2.example.com was pointed to these two IPs. > > Will this cause problems, for example, the duplicated notification or > zone-transfer? Duplicated notifications - yes, unless you explicitly configure master server not to send for one of these IPs. And I'm not sure it's worth the effort. Duplicate zone transfers - I think no, but I'm not sure how will bind handle it. probably the best method would be to try it out. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
On 07/07/11 04:56, pa...@laposte.net wrote: > > Hello, > > I got two different forms of AUTHORITY SECTION from the dig, for example, > > $ dig mydots.net @ns7.dnsbed.com > > ; <<>> DiG 9.4.2-P2.1 <<>> mydots.net @ns7.dnsbed.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36520 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;mydots.net. IN A > > ;; AUTHORITY SECTION: > mydots.net. 3600 IN SOA ns7.dnsbed.com. support.dnsbed.com. 6 10800 3600 > 604800 3600 This one means that there's no such record. Your answer is empty. See, you don't have answer section and RFCs state that authorative nameservers should send SOA record in authority section if there's no data. > > ;; Query time: 90 msec > ;; SERVER: 58.22.107.162#53(58.22.107.162) > ;; WHEN: Thu Jul 7 09:54:07 2011 > ;; MSG SIZE rcvd: 86 > > > > $ dig www.mydots.net @ns7.dnsbed.com > > ; <<>> DiG 9.4.2-P2.1 <<>> www.mydots.net @ns7.dnsbed.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3327 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.mydots.net. IN A > > ;; ANSWER SECTION: > www.mydots.net. 900 IN A 61.144.56.101 > > ;; AUTHORITY SECTION: > mydots.net. 3600 IN NS ns7.dnsbed.com. > mydots.net. 3600 IN NS ns8.dnsbed.com. And this one has correct answer, and the NS records are there just in case - to notify you that you got your answer from authorative ns and what other authorative ns'es are. Torinthiel signature.asc Description: OpenPGP digital signature ___ 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: SPF implementation schedule.
On 2011-07-12 10:07, kalpesh varyani wrote: Looking at zytrix and spf2 sites, it seems that SPF is yet to be implemented at functional level. RFC4408 documentation suggests method to implement SPF. However, I need to know if ISC is planning to provide support for SPF at client and/or server side. Will anyone from ISC like to comment? I'm not from ISC as well, but as Eivind has already stated - BIND already supports EVERYTHING there is on DNS server/resolver side. It serves SPF records, allows to fetch them, and there's nothing more from DNS you can require. What remains is *mailserver's* side to query for said SPF records and act accordingly. And this does not belong to ISC, but to your mailserver's provider. Postfix can do this by external plugins, some others probably as well but I haven't tested it. Regards, Torinthiel On Mon, Jul 11, 2011 at 7:42 PM, Eivind Olsen mailto:eiv...@aminor.no>> wrote: kalpesh varyani wrote: > Does ISC implement SPF for server or client side currently? > If yes, then where to get the libraries; if not then what is the > scheduled date/release for implementation? I'm not ISC, and anything I say may be completely wrong. Ok, that's the disclaimer done with... BIND support for SPF extends as far as being allowed to put SPF records into zones. As far as I know BIND does not have any libraries or functions to actually make much sense of the content of SPF records, which is what I'm guessing you're really looking for. Perhaps something like libspf (http://www.libspf2.org <http://www.libspf2.org/>) is what you want? Regards Eivind Olsen ___ 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: SPF implementation schedule.
On 2011-07-12 11:07, almah...@ranksitt.net wrote: Hi, I have fallen in problem with my dns server. Some times , some specific domain can't resolve. From log report (/var/log/messages) i have given log for that. And what does this has in common with the thread you've replied to? Jul 12 11:17:44 ns1 named[14948]: client 178.33.222.134#38772: query (cache) 'rankstel.net/MX/IN' denied Jul 12 11:17:45 ns1 named[14948]: client 212.204.41.82#44529: query (cache) 'rankstel.net/MX/IN' denied Jul 12 11:17:48 ns1 named[14948]: client 212.204.41.82#64402: query (cache) 'rankstel.net/MX/IN' denied Looks like rankstel.net is delegated to two nameservers (see dig ns rankstel.net @e.gtld-servers.net.): ns1.ranksitt.net. (which refuses to answer for it) and ns1.rankstel.net. (which times out). So, rankkstel.net is broken, you cannot do anything with it. Jul 12 11:17:49 ns1 named[14948]: client 69.73.138.12#55591: query (cache) 'era.com.bd/MX/IN' denied And era.com.bd is delegated to ns2.ranksitt.net., ns1.ranksitt.net. and dns.bankasia.com.bd. And I see three different answers from those servers. Only ns2.ranksitt.net seems to be configured correctly (But I haven't dig any deeper). Note, I've not tested it deeply, so it might be wrong. Regards, Torinthiel ___ 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: master slave different site different resolution
On 2011-07-14 11:53, Gabriele Gabriele wrote: Ok, may be I was not so clear to explain.. for example I have in my Master work site the our webmail "webmail.mydomain.com" that when Master work site in UP the resolution is 1.1.1.1 but if the master go down in My slave work site, my slave dns resolv "webmail.mydomain.com" with 1.1.1.1 but that site is down. So it should resolv it with my backup/slave resolution 2.2.2.2 So, you have both DNS and HTTP servers on both 1.1.1.1 and 2.2.2.2? And you want HTTP traffic to go to 1.1.1.1, except where it fails, than it should switch to 2.2.2.2? First, you do realize that you need to thing of some way to synchronize those web servers. Second, if those are synchronized, why don't just put both IP addresses and have some weak load balancing? If you really want IP to change when server fails, this is bad: a) takes time to propagate - after failure you still have to wait TTL seconds before everyone uses new server. b) puts more burden on your DNS servers and on clients, as you have to put short TTLs on those names c) you have to develop a way to test for primary's site failure. And take care of false-positives. d) you can't have normal master-slave setup, which leads to zone maintenance problems. Regards, Torinthiel > Date: Thu, 14 Jul 2011 17:42:56 +0800 > Subject: Re: master slave different site different resolution > From: short...@gmail.com > To: d_gabri...@hotmail.it > CC: bind-users@lists.isc.org > > 2011/7/14 Gabriele Gabriele : > > Dear lists, > > > > I have an issue to resolve about 2 dns server Master/Slave. > > > > > > The Master is positioned in a site with public ip 1.1.1.1 and all the public > > dns resolutions point to 1.1.1.1 > > the Slave is positioned in a site whit public ip 2.2.2.2 and obviously all > > the public dns resolutions point to 1.1.1.1 > > > > > > the problem born when my Master site go down, because the Slave should > > change the dns public resolution whit 2.2.2.2 > > is it possible use bind for this? > > > > > Sorry my bad understanding for your statement. > But since you have two servers, two public IPs, why not just publish > these two as authority or cache only servers? > > Regards. ___ 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: authoritative server is not caching?
On 2011-07-19 11:40, pa...@laposte.net wrote: Hello, I want to make sure that if the authoritative server won't cache > anything even if the authoritative answer from itself? Coz I saw > the book Pro DNS and BIND says: The (authoritative) name server > does not cache. Authoritative server cannot cache anser from itself. Cache is for answers a server has received from somewhere, while authoritative answers come directly from zone data. Torinthiel ___ 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: rndc: 'addzone' failed: permission denied
On 2011-08-17 15:24, Fredrik Poller wrote:
Hello,
I'm trying to use the new addzone feature in rndc, but all I get is the
following error message:
# rndc addzone 'example.com in external { type slave; file "example.com";
masters { 192.168.142.133; }; };'
rndc: 'addzone' failed: permission denied
rndc is configured and works well with other commands.
The bind log file doesn't tell me anything, despite increasing the trace level,
it only acknowledges that the request was received. Running rndc with -V
doesn't reveal anything useful.
I've tried with and without views, I've tried to add both master and slave
zones with different filenames (both relative and full path). Out of
desperation I've also instituted some very liberal file permissions on
everything named related, but no luck.
Do you use chroot jail? Maybe the paths are different, and that's why it
fails. Also, does 'very liberal' mean a+rwX, or something else? Bind
might be trying to write as a user you are not expecting.
Regards,
Torinthiel
___
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: Max number of views and performance.
On 08/24/11 16:03, Chris Buxton wrote: > Views are tested in order. The first view that matches (by match-* > statements), wins. There is no default unless you create one as the last > view, typically without any match-* statements -- the default is to > match all requests. > > 1 million views sounds to me like a recipe for disaster. The time to run > through all of the match-clients statements would probably be excessive, > and the memory requirements would likely be huge. And one question remains: Why would anyone need such a setup. Torinthiel signature.asc Description: OpenPGP digital signature ___ 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: [UNsolved] was: what does dig +trace do?
On 09/01/11 17:56, Tom Schmitt wrote: > > I found the cause of my problem (and a solution): > > dig +trace actually has another behaviour than doing the trace manually step > by step with dig. > > > For a trace, dig is asking for the NS-records, then for the IP-address of the > nameserver found and then go on asking this nameserver. Till the destination > is reached. > > In my case, dig is asking for the nameservers of the root-zone and is getting > the answer: > . IN NS root1 > . IN NS root2 > etc > > Next dig is asking for the A-record of root1. And here is the differrence: > > If I do "dig root1" dig is asking exactly this, it is asking for the A-record > of root1. And of course I get the correct answer from named. > > The +trace option does not do this! > Instead, the +trace-option is using the searchsuffix in the resolv.conf and > is asking for root1.my.search.suffix. and NOT for root1. > This is why the +trace option fails every time. > > After deleting the searchsuffix in resolv.conf, dig +trace is working fine > without any error. > > In my oppinion it's a bug that dig +trace behave in a differrent way than > doing the queries with dig one by one. No, IMHO, it's a bug in your root zone. Names without dot at end are relative. Change your root zone to say . IN NS root1. . IN NS root2. (with dots appended) and you should be home. signature.asc Description: OpenPGP digital signature ___ 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: ZSK pre-publish
On 2011-10-01 11:40, Matthew Seaman wrote: The trick is to use dnssec-settime modify the dates built into your key by dnssec-keygen. Or equivalently to use dnssec-keygen with appropriate flags to set the 'Activate' date (not to mention Inactive and Delete) some time in the future. So --- this key is active now: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+04664.private Created: Sat Aug 13 07:40:28 2011 Publish: Sat Aug 13 07:40:28 2011 Activate: Sat Sep 10 07:40:28 2011 Revoke: UNSET Inactive: Sat Oct 8 07:40:28 2011 Delete: Sat Oct 8 07:40:28 2011 but this key is only published and will activate in a week: % dnssec-settime -p all Kinfracaninophile.co.uk.+005+44132.private Created: Sat Sep 10 09:01:24 2011 Publish: Thu Jan 1 01:00:00 1970 Activate: Sat Oct 8 09:01:24 2011 Revoke: UNSET Inactive: Sat Nov 5 08:01:24 2011 Delete: Sat Nov 5 08:01:24 2011 dnssec-signzone will grok all the built-in dates and do the right thing when you sign the zone. BTW, how does dnssec-signzone behave when you pass -s option? Does it take into account that date when determining whether to use/publish key? Can one for example generate signatures for the future using dnssec-signzone, or is it possible only with careful manual inclusion? Regards, Torinthiel ___ 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: Resign a zone
On 2011-11-08 10:34, rams wrote: Hi , I have signed zone and already i have resigned two times. Now again i am resigning zone but after resign zone , RRSIG values are not changed. the same old values displaying. Any wrong in me. Could you please guide me how to change RRSIG values. There could be several issues with this, please give some more info. How are you signing your zone? dnssec-signzone? automatically using bind? Some other software? If you're using dnssec-signzone and pass it old signed zone data it regenerates signatures only if signature end time falls within a period defaulting to 1/4 signature valitity time (so with default signature period it's 7.5 days). If you re-sign your zone say 10 days in advance, it won't change old signatures. You can change it with -i. Other software probably behaves similarly. Also, if you're signing your zone off-line and upload it to bind, did you remember to change SOA and reload master? Regards, Torinthiel ___ 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
