Re: Forward sub-domains to another domain
yes, for sure, if author wants to forward all subdomains of a particular domain. 2010/1/27 moto kawasaki > > > CNAME is what you need > > or DNAME, isn't it? > > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward sub-domains to another domain
> CNAME is what you need or DNAME, isn't it? -- moto kawasaki ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward sub-domains to another domain
CNAME is what you need 2010/1/27 Xico leite > Hi all, > > someone knows how to forward a sub-domain to another domain thru bind?... > i mean i have cache.leite.us and i want to point to leite4.uni.cc, how can > i do that?... > > Thank you! > > ___ > 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
Forward sub-domains to another domain
Hi all, someone knows how to forward a sub-domain to another domain thru bind?... i mean i have cache.leite.us and i want to point to leite4.uni.cc, how can i do that?... Thank you! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: is it possible to dynamically update an RRSIG record?
>Jack Tavares wrote: >> Looking at the code for libbind, specifically >> res_nmkupdate, >> there is no case statement for RRSIG records. >> >> In this case, I was trying to update the TTL. >> Is that not allowed intentionally? > >I think so. The TTL of a RRSIG RR *MUST* match the TTL value of the >RRset it covers. > >Hugo Hmm. Well then i guess one cannot update the TTL of the RRSIG itself, since if it must match the RRset it covers, then the TTL on the RRSET must be changed at which time bind would resign the records. ___ 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
Name resolution follows forwarders instead of delegations on master server
I've noticed that if I have default forwarders setup in the options
section of my named.conf, then BIND (9.4.1-P1) will forward to these
servers rather than following the delegations for zones where it's
authoritative (verified via sniffer trace). Is this true of all BIND
versions?
In my case, the forwarders in the options section are in my primary data
centre which is authoritative for all of our internal zones, and the
config below exists in one our geographical data centers (overseas),
which is master only a subset of the zones. Since the delegation is to a
local F5 GTM in that same geographical datacenters, I really don't want
everything coming back across the WAN, only to be delegated back across
the WAN again (lots of inefficiencies). I've found that putting an empty
forwarders statement in the zone config (e.g. forwarders { };) prevents
following the default forwarders, so I have a workaround for now.
This behavior seems a little counter-intuitive to me and never caused me
any problems until recently. So I wanted to know if this behavior was
consistent across all BIND versions, or if it only happened recently due
to our BIND version upgrade last year (9.4.1-P1). I'm looking at another
code upgrade shortly, so want to ensure no surprises...
Any help/clarification is appreciated
Here's a simplified config of what I'm running. In this case, queries to
this DNS server (172.16.1.1), will be forwarded to 10.1.1.1 & 10.2.2.2
first, then if no reply it will try the NS servers for appx listed in
the zone file (delegated to a global load balancer):
NAMED.CONF
~~~
Options {
directory "/var/named";
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };
forwarders { 10.1.1.1; 10.2.2.2; };
};
Zone "internal.corp.sample" in {
type master;
file "db.internal.corp.sample";
allow-update { none; };
allow-transfer { internal-acl-list; };
};
Db.internal.corp.sample
~~
@ IN SOA ;(...the usual stuff)
IN NS 172.16.1.1
IN NS 172.16.2.2
IN NS 10.1.1.1
IN NS 10.2.2.2
appx IN NS 172.16.3.3
appx IN NS 172.16.4.4
Gord Taylor (CISSP, GCIH, GEEK) | Senior Network Analyst, Internet
Technologies | Royal Bank of Canada
___
This e-mail may be privileged and/or confidential, and the sender does not waive
any related rights and obligations. Any distribution, use or copying of this
e-mail or the information
it contains by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or
otherwise) immediately.
Ce courriel peut contenir des renseignements protégés et confidentiels.
Lexpéditeur ne renonce pas aux droits et obligations qui sy rapportent.
Toute diffusion, utilisation ou copie de ce courriel ou des renseignements
quil contient
par une personne autre que le destinataire désigné est interdite.
Si vous recevez ce courriel par erreur, veuillez men aviser immédiatement,
par retour de courriel ou par un autre moyen.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: update failed: SERVFAIL
In message <2ac8e9ad1001250710s2489d1edpf5a247341bc2a...@mail.gmail.com>, xu do ng writes: > Hi, >I have a problem about the DDNS ,When I nsupdated the master dns server > under with dnssec,but it failed as following: > > *r...@root:/var/named/chroot/etc# nsupdate -d > > server 192.168.225.130 5353 > > update add test.net 900 A 5.5.5.5 > > > Reply from SOA query: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32603 > ;; flags: qr aa ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;test.net.IN SOA > > ;; AUTHORITY SECTION: > net. 300 IN SOA dns.net. dns.net. > 2010011806 10800 60 604800 10800 > > Found zone name: net > The master is: dns.net > Sending update to 192.168.225.130#5353 > Outgoing update query: > ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 30960 > ;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 0 > ;; UPDATE SECTION: dns.net. 900 IN A 5.5.5.5 > > Reply from update query: > ;; ->>HEADER<<- opcode: UPDATE, status: SERVFAIL, id: 30960 > ;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 > > * > > But when i nsupdated the master dns server without dnssec, it succeed. So I > don't know why? Did you look at the master's logs? Have you told named where the private keys are? Are the private keys readable by named? > -- > - > Xudong > email=a3=baxudon...@gmail.com > Beijing,China > - > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question!
Also you did not *buy* the addresses from RIPE as RIPE does not *sell* addresses. You leased the addressed from RIPE. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Disabling recursion causes browser hangs on clients with auto proxy config
Thanks very much to everyone who replied and explained this set
of problems in such detail to me. It's now clear as day and of
course you are correct. You have made my day. :-)
As for "allow-query" instead of "allow-recursion" - I see what
you mean, the stub resolvers seem to react differently to
"recursion not available" than they do for flat out "refused",
especially when there are more than one name servers configured.
However I cannot refuse because the clients still need to be
able to resolve our zones. I will work something out for this,
so thanks for that hint as well.
Regards
Frank
- Originalnachricht -
Von: "Kevin Darcy"
Gesendet: Die, 26.1.2010 00:08
An: bind-users@lists.isc.org
Betreff: Re: AW: Disabling recursion causes browser hangs on clients with auto
proxy config
On 1/25/2010 2:47 PM, Niall O'Reilly wrote:
> Frank Stanek wrote:
>> I'm sorry but I don't quite understand what you mean. Could you
>> please elaborate this on the basis of this excerpt from our pac
>> file?
>>
>> function FindProxyForURL(url, host)
>> {
>> var proxy1 = "PROXY 192.168.240.29:8080";
>> var proxy2 = "PROXY 172.16.1.30:8080";
>> if ( dnsDomainIs(host, ".intern")
>> || shExpMatch(url, "*//localhost*")
>> || shExpMatch(url, "*//127*")
>
> So far so good: you've tried to match part of the text of the
> URL against each of those rules.
>
>> || isInNet(host, "192.168.1.0", "255.255.255.0")
>> // more lines with subnets
>
> Before applying this rule, your browser has to convert the
> domain name given in the URL to an address, in order to check
> whether the address belongs to the subnet. Since you've
> chosen to block recursive name resolution, this rule will fail
> except for domain names for which your name server is
> authoritative; likewise for "more lines with subnets".
>
Good analysis.
More generally,
1) isInNet() or any other function which causes constant DNS lookups is
bad from a DNS infrastructure point of view, and can run into caching
complications
2) any form of access control which involves turning off recursion for
particular clients is iffy, since stub resolvers don't react
consistently to unexpected lookup results such as referrals. It is
generally better to give a definitive REFUSED response, in order to make
one's intent clear. In BIND terms, that would be "allow-query" rather
than "allow-recursion".
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
