Re: question about CNAME
On Thu, Mar 12, 2009 at 12:32:35PM +0800, tzq tang gelenbert...@gmail.com wrote a message of 132 lines which said: I think I should explain the question more clearly, You need first to learn about email. The superior to sign is here to *quote* what you respond to. Do not use it for your own text or it will be quite difficult to read. email.xx A 12.2.23.4 http://email.xx.xxx.com/ :-) The format of the right-hand side will probably not be accepted by BIND :-) and in another DNS server I add an CNAME record as follows: email CNAME email.xx.zone.com http://email.xx.xxx.com/. but it dosen't work.who can tell me why ? Invalid syntax. BIND will tell you that at startup. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: XFR quota setting?
On Mar 11 2009, Niall O'Reilly wrote: On Wed, 2009-03-11 at 16:41 -0500, Peter Laws wrote: Seriously, though, what is the default quota and is it actually configurable? Sorry. No idea what or whether. RTFM time for us both! 8-) Which ought to take less than the time to post here :-( options transfers-out setting, default 10. Although the '... quota reached' messages alarmed me at first, the following message announcing recovery (confirmed by manual checking of SOA serials) reassured me enough to make me feel that no further attention was needed. If it's occurring a lot, you could have stuck or nearly-stuck transfers going on. rndc status will tell you how many. You may need to adjust max-transfer-time-out/max-transfer-idle-out rather than transfers-out. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Two outgoing queries for each incoming query
Is this possible with 9.6.0-P1 or do I need to change the code (all ideas where to start are welcome, I haven't looked at the code yet). I want to setup a forwarder and each incoming query (in fact only A or ) should be sent to two different upstream servers. Joe ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Two outgoing queries for each incoming query
On Thu, Mar 12, 2009 at 7:43 AM, My Name mylistuser1...@gmail.com wrote: I want to setup a forwarder and each incoming query (in fact only A or ) should be sent to two different upstream servers. Why? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: XFR quota setting?
On Mar 11 2009, Niall O'Reilly wrote: On Wed, 2009-03-11 at 16:41 -0500, Peter Laws wrote: Seriously, though, what is the default quota and is it actually configurable? Sorry. No idea what or whether. RTFM time for us both! 8-) Which ought to take less than the time to post here :-( options transfers-out setting, default 10. Yes, but if you're grepping for xfer, you'll never find that. Thanks, though, this is what I wanted to know. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Two outgoing queries for each incoming query
Date: Thu, 12 Mar 2009 13:43:44 +0200 Subject: Two outgoing queries for each incoming query From: My Name mylistuser1...@gmail.com To: bind-users@lists.isc.org Is this possible with 9.6.0-P1 or do I need to change the code (all ideas where to start are welcome, I haven't looked at the code yet). I want to setup a forwarder and each incoming query (in fact only A or ) should be sent to two different upstream servers. Why? Bind already does this. If there are two (or more) servers serving a zone, it will already query all of them for the initial query. However, it uses the answer from the server that has the fastest response time. Regards, Gregory Hicks - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Peaceful coexistence with Windows domain
Our environment includes a couple of AD servers. They serve DNS to PCs using AD (but not all PCs). They allow DDNS for clients and slave the rest of our environment's zones. For some reason, they *forward* every other query to us, but never mind that. Look it up your own damn ... well, never mind. At any rate, we don't actually delegate their zone to them. This causes problems, as you can imagine. I'm told that the reason we're doing things this way is that we don't want any of those internal addresses to be queried by the unwashed masses lurking outside our perimeter. So my thought was, well, let's delegate the zone to the AD servers. Since they are already ACLed (or whatever MS calls it), no one will be able to see their records off-campus but on-campus folks will be able to (finally) resolv addresses in that zone regardless of where they point (internally) for DNS. Except that they need an MX record for that zone. So adding the NS record to delegate the zone to them properly meant that no one could see the MX from the outside (since the MS-DNS is ACLed). If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. We thought of slaving that zone on the master, but then we run into security, who doesn't want any of that internal information leaked out. No problem, since we're slaving the zone, we'll pop an ACL on it. Problem solved! Hurray. Except for that MX record. Once you delegate a zone, you *delegate* the zone. The MX is invisible. So my requirements are to 1) allow that MX record to be seen outside, 2) allow any host in our environment to be able to query names in any zone regardless of which system they point at for DNS, and 3) not have any records in that zone be visible outside save for that MX. I'm assuming that switching our configuration to use views would help, but we'd like to avoid that, at least for now. Any quick fixes? I checked, and per the MS-People, MS-DNS cannot put ACLs on particular records. Neither can BIND, so no surprise there. Which rock do I need to look under? -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology pl...@ou.edu --- Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Two outgoing queries for each incoming query
In message 200903121454.n2cesvel019...@metis.hicks-net.net, Gregory Hicks wri tes: Date: Thu, 12 Mar 2009 13:43:44 +0200 Subject: Two outgoing queries for each incoming query From: My Name mylistuser1...@gmail.com To: bind-users@lists.isc.org Is this possible with 9.6.0-P1 or do I need to change the code (all ideas where to start are welcome, I haven't looked at the code yet). I want to setup a forwarder and each incoming query (in fact only A or ) should be sent to two different upstream servers. Why? Bind already does this. If there are two (or more) servers serving a zone, it will already query all of them for the initial query. However, it uses the answer from the server that has the fastest response time. No. It will query multiple servers in turn as needed to satisfy queries. RTT estimates are most effective with infrastructure zones as those are the ones queried most often. Named tries to minimize the number of queries it makes. Regards, Gregory Hicks - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Peaceful coexistence with Windows domain
Peter Laws wrote: Our environment includes a couple of AD servers. They serve DNS to PCs using AD (but not all PCs). They allow DDNS for clients and slave the rest of our environment's zones. For some reason, they *forward* every other query to us, but never mind that. Look it up your own damn ... well, never mind. At any rate, we don't actually delegate their zone to them. This causes problems, as you can imagine. I'm told that the reason we're doing things this way is that we don't want any of those internal addresses to be queried by the unwashed masses lurking outside our perimeter. So my thought was, well, let's delegate the zone to the AD servers. Since they are already ACLed (or whatever MS calls it), no one will be able to see their records off-campus but on-campus folks will be able to (finally) resolv addresses in that zone regardless of where they point (internally) for DNS. Except that they need an MX record for that zone. So adding the NS record to delegate the zone to them properly meant that no one could see the MX from the outside (since the MS-DNS is ACLed). If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. We thought of slaving that zone on the master, but then we run into security, who doesn't want any of that internal information leaked out. No problem, since we're slaving the zone, we'll pop an ACL on it. Problem solved! Hurray. Except for that MX record. Once you delegate a zone, you *delegate* the zone. The MX is invisible. So my requirements are to 1) allow that MX record to be seen outside, 2) allow any host in our environment to be able to query names in any zone regardless of which system they point at for DNS, and 3) not have any records in that zone be visible outside save for that MX. I'm assuming that switching our configuration to use views would help, but we'd like to avoid that, at least for now. Any quick fixes? I checked, and per the MS-People, MS-DNS cannot put ACLs on particular records. Neither can BIND, so no surprise there. Which rock do I need to look under? You can't really have it both ways, either the zone is visible or it isn't. The MX record is at the very top of the zone -- what is often called the apex -- so it's not like you can delegate it and put an ACL on the delegated zone. It seems a little inconsistent to me that your Security folks don't mind the MX record being exposed but they're paranoid about the zone's other internal stuff leaking out. I don't see any way to to meet the requirements you've been given, as you've described them. There's nothing really unusual about having separate internal-versus-external versions of your namespace, and the delegation structure doesn't need to be the same for both. So why not just stick with an undelegated AD zone in the external version? You can still delegate it in the internal version, if it makes you feel better. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Peaceful coexistence with Windows domain
If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. Is there a reason why you can't point all of your internal hosts (AD and non-AD) at your AD's for resolution? From: bind-users-boun...@lists.isc.org on behalf of Peter Laws Sent: Thu 3/12/2009 4:51 PM To: bind-us...@isc.org Subject: Peaceful coexistence with Windows domain Our environment includes a couple of AD servers. They serve DNS to PCs using AD (but not all PCs). They allow DDNS for clients and slave the rest of our environment's zones. For some reason, they *forward* every other query to us, but never mind that. Look it up your own damn ... well, never mind. At any rate, we don't actually delegate their zone to them. This causes problems, as you can imagine. I'm told that the reason we're doing things this way is that we don't want any of those internal addresses to be queried by the unwashed masses lurking outside our perimeter. So my thought was, well, let's delegate the zone to the AD servers. Since they are already ACLed (or whatever MS calls it), no one will be able to see their records off-campus but on-campus folks will be able to (finally) resolv addresses in that zone regardless of where they point (internally) for DNS. Except that they need an MX record for that zone. So adding the NS record to delegate the zone to them properly meant that no one could see the MX from the outside (since the MS-DNS is ACLed). If I dump the delegation and make an MX record in the master, mail will be OK, but then no one can query records in that zone because it's not actually delegated unless they point at MS-DNS. We thought of slaving that zone on the master, but then we run into security, who doesn't want any of that internal information leaked out. No problem, since we're slaving the zone, we'll pop an ACL on it. Problem solved! Hurray. Except for that MX record. Once you delegate a zone, you *delegate* the zone. The MX is invisible. So my requirements are to 1) allow that MX record to be seen outside, 2) allow any host in our environment to be able to query names in any zone regardless of which system they point at for DNS, and 3) not have any records in that zone be visible outside save for that MX. I'm assuming that switching our configuration to use views would help, but we'd like to avoid that, at least for now. Any quick fixes? I checked, and per the MS-People, MS-DNS cannot put ACLs on particular records. Neither can BIND, so no surprise there. Which rock do I need to look under? -- Peter Laws / N5UWY National Weather Center / Network Operations Center University of Oklahoma Information Technology pl...@ou.edu --- Feedback? Contact my director, Craig Cochell, cra...@ou.edu. 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
Re: question about CNAME
thanks for your response.I do this test between two intranet machine and each of them has a local IP.10.0.0.13,additionally the both domain are in the same DNS SERVER 10.0.0.13 ,the zone file as follows: ZONE 1: $ORIGIN . $TTL 86400 ; 1 day test.comIN SOA test.com. www.test.com. ( 19970229 ; serial 10 ; refresh (10 seconds) 10 ; retry (10 seconds) 30 ; expire (30 seconds) 30 ; minimum (30 seconds) ) NS localhost. A 10.0.0.13 $ORIGIN test.com. 1 PTR localhost. email CNAME email.tzqian.com. ZONE 2: $ORIGIN . $TTL 86400 ; 1 day tzqian.com IN SOA tzqian.com. support.tzqian.com. ( 1997022706 ; serial 10 ; refresh (10 seconds) 10 ; retry (10 seconds) 30 ; expire (30 seconds) 30 ; minimum (30 seconds) ) NS localhost. A 10.0.0.13 $ORIGIN tzqian.com. 1 PTR localhost. email A 10.0.0.1 On Thu, Mar 12, 2009 at 7:55 PM, Scott Haneda talkli...@newgeo.com wrote: Can you just post your zone file, copy and paste, and do not change any data in it, use real IP's. Or at least obfuscate them in a way that makes sense to the rest of us. There really is not a lot of sense in obfuscating a public data store anyway. Here is an example: Server #1 email.serverIN A 192.168.1.100 Server #2 email IN CNAME email.server.yourzone.com. I am still not sure I understand your issues, you need to show us both zones, and tell us each zones host name. On Mar 11, 2009, at 7:28 PM, tzq tang wrote: I think I should explain the question more clearly,I am wondering how cname reflect the address,so I do a test in my server to add an A record as follows (zone.com): email.xx A 12.2.23.4 and in another DNS server I add an CNAME record as follows: email CNAME email.xx.zone.com. but it dosen't work.who can tell me why ? -- Scott * If you contact me off list replace talklists@ with scott@ * ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trouble publishing dkim via nsupdate
In message 20090313031347.ga19...@csy.ca, Shane W writes: Hey all, I am trying to publish a dkim record in a signed dynamic zone using nsupdate. My query looks like the below but nsupdate is having none of it, giving formerr. Can anyone see an obvious error with this query: Pasting the entry directly into the zone (freeze/thaw) does work but then the record doesn't get signed. nsupdate: zone csy.ca update delete continuum._domainkey.csy.ca any update add continuum._domainkey.csy.ca 86400 txt k=rsa\; t=y\; p=MIGfMA0GCSq GSIb3DQEBAQUAA4GNADCBiQKBgQDGDqQOjvR2NkesUp+rMl164OdruvyT/hcvwWpPJVZZpYJ7C0rU FoZeGdIsi0Riv8wbMd0YspPEfXEslt+neNBTp+nGtkbzpV23PnVwxaqaCpUOZtc7LN2BTKLnpQATL 30JJE6LwafHPmM5I9S6y1pBQBV9KLdBuxG4+xlIwQf6HwIDAQAB send Remove the any from the delete command. update delete continuum._domainkey.csy.ca output with -d Reply from SOA query: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11757 ;; flags: qr aa rd ra ; QUESTION: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;csy.ca.ANY SOA ;; ANSWER SECTION: csy.ca. 86400 IN SOA continuum.ns.csy.ca. hostmast er.csy.ca. 207 14400 900 2419200 3600 ;; AUTHORITY SECTION: csy.ca. 86400 IN NS dme6.ns.csy.ca. csy.ca. 86400 IN NS dme7.ns.csy.ca. csy.ca. 86400 IN NS continuum.ns.csy.ca. csy.ca. 86400 IN NS dme5.ns.csy.ca. ;; ADDITIONAL SECTION: dme5.ns.csy.ca. 86400 IN A 63.219.151.12 dme6.ns.csy.ca. 86400 IN A 64.246.42.203 dme7.ns.csy.ca. 86400 IN A 205.234.170.139 continuum.ns.csy.ca.3600IN A 70.71.3.27 Found zone name: csy.ca The master is: continuum.ns.csy.ca Sending update to 70.71.3.27#53 Outgoing update query: ;; -HEADER- opcode: UPDATE, status: NOERROR, id: 2080 ;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 0 ;; ZONE SECTION: ;csy.ca.ANY SOA ;; UPDATE SECTION: continuum._domainkey.csy.ca. 0 ANY ANY continuum._domainkey.csy.ca. 86400 ANY TXT k=rsa\; t=y\; p=MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDGDqQOjvR2NkesUp+rMl164OdruvyT/hcvwWpPJVZZpYJ7C0rUF oZeGdIsi0Riv8wbMd0YspPEfXEslt+neNBTp+nGtkbzpV23PnVwxaqaCpUOZtc7LN2BTKLnpQATL3 0JJE6LwafHPmM5I9S6y1pBQBV9KLdBuxG4+xlIwQf6HwIDAQAB Reply from update query: ;; -HEADER- opcode: UPDATE, status: FORMERR, id: 2080 ;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 Thanks, Shane ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
