Re: Custom DNS error with BIND?
--On 5. oktober 2010 22.25.17 +0700 Phan Quoc Hien phanquoch...@gmail.com wrote: I'm find the way to custom DNS error with BIND. Below I explained it: It A record not exist = return to one IP to redirect custom error page with apache! Like OpenDNS? Please let me know how to solve this problem...or must edit bind source code? On Tue, Oct 5, 2010 at 11:20 PM, Eivind Olsen eiv...@aminor.no wrote: As far as I know, it's not natively supported by BIND. Are you _really_ sure you want this? Suggested reading is for example http://en.wikipedia.org/wiki/DNS_hijacking On 05.10.10 23:24, Phan Quoc Hien wrote: Thank for your respond. I find for testing purpuse only. like, testing how DNSSEC validation fails for such names? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. A day without sunshine is like, night. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.2-P2 is now available.
Hi Florian, It's this one which is also in 9.6-ESV-R2: 2869. [bug] Fix arguments to dns_keytable_findnextkeynode() call. RT #20877] Regards, Cathy On 03/10/10 11:06, Florian Weimer wrote: * Mark Andrews: * If BIND, acting as a DNSSEC validating server, has two or more trust anchors configured in named.conf for the same zone (such as example.com) and the response for a record in that zone from the authoritative server includes a bad signature, the validating server will crash while trying to validate that query. Does this change need backporting to 9.6-ESV? Is an isolated patch available? ___ 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: Unable to query the nameserver
On 10/5/2010 3:49 PM, Dotan Cohen wrote: On Tue, Oct 5, 2010 at 20:30, Eivind Olseneiv...@aminor.no wrote: However, another site that _does_ work (with both nameservers on this host, not just ns1) shows the same thing: # nslookup ns1.sharingserver.eu 178.63.65.136 Server: 178.63.65.136 Address:178.63.65.136#53 ** server can't find ns1.sharingserver.eu: NXDOMAIN How do you mean this one is working? It's working just as badly as your first example. Yes, but typing the domain into Firefox brings up the webpage that I've put on that server! You're introducing a bunch of other variables when you use a browser to troubleshoot a DNS resolution problem: 1) The browser might have cached the DNS response 2) The browser might have cached the web content itself and not be performing DNS lookups 3) The browser might be using a PAC (proxy auto-config) file which shuffles the request off to some proxy I would suggest sticking to DNS troubleshooting tools to troubleshoot DNS. And dig/host is to be greatly preferred for that purpose over nslookup, which sucks in more ways than I care to list here. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
Date: Wed, 06 Oct 2010 10:35:32 -0400 From: Kevin Darcy k...@chrysler.com Sender: bind-users-bounces+oberman=es@lists.isc.org On 10/5/2010 3:49 PM, Dotan Cohen wrote: On Tue, Oct 5, 2010 at 20:30, Eivind Olseneiv...@aminor.no wrote: However, another site that _does_ work (with both nameservers on this host, not just ns1) shows the same thing: # nslookup ns1.sharingserver.eu 178.63.65.136 Server: 178.63.65.136 Address:178.63.65.136#53 ** server can't find ns1.sharingserver.eu: NXDOMAIN How do you mean this one is working? It's working just as badly as your first example. Yes, but typing the domain into Firefox brings up the webpage that I've put on that server! You're introducing a bunch of other variables when you use a browser to troubleshoot a DNS resolution problem: 1) The browser might have cached the DNS response 2) The browser might have cached the web content itself and not be performing DNS lookups 3) The browser might be using a PAC (proxy auto-config) file which shuffles the request off to some proxy I would suggest sticking to DNS troubleshooting tools to troubleshoot DNS. And dig/host is to be greatly preferred for that purpose over nslookup, which sucks in more ways than I care to list here. I keep hoping for a BIND distro that upgrades nslookup(1) to: print STDERR, nslookup(1) has been replaced by host(1)\n; exit 0; I've been wishing that nslookup would go away since back in BIND-v4 days. I could save a lot of troubleshooting time if I didn't get trouble reports based on the use of nslookup that is misleading or not completely bogus. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 7/10/10 1:47 AM, Kevin Oberman wrote: I keep hoping for a BIND distro that upgrades nslookup(1) to: print STDERR, nslookup(1) has been replaced by host(1)\n; exit 0; Wasn't nslookup already deprecated about ten years or so ago? Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
Date: Thu, 07 Oct 2010 01:53:29 +1100 From: Ben McGinnes b...@adversary.org On 7/10/10 1:47 AM, Kevin Oberman wrote: I keep hoping for a BIND distro that upgrades nslookup(1) to: print STDERR, nslookup(1) has been replaced by host(1)\n; exit 0; Wasn't nslookup already deprecated about ten years or so ago? I can find nothing in the documentation that states such. If I missed it, I'd appreciate someone pointing me at it. I quit using nslookup over 16 years ago (since it was before I moved to my current job) and have an near automatic response of Could you check this using 'host'? Often that is followed by a dig command they can cut and paste if they are not on Windows. dig(1) is clearly the ideal choice, but it's really a bit too much for normal users other than as cut 'n' paste. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 7/10/10 2:09 AM, Kevin Oberman wrote: I can find nothing in the documentation that states such. If I missed it, I'd appreciate someone pointing me at it. I have some vague memory of seeing messages to that effect when using it on a Solaris system in around 1999. I stopped using it around then and switched to host and dig. I can't point you to specific documentation (I stopped caring when I started using dig), but I did find these: http://cr.yp.to/djbdns/nslookup.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html As far as I'm aware it only hung around because it was available on Windows NT/2K/etc., while host and dig were not. Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 10/6/2010 11:44 AM, Ben McGinnes wrote: On 7/10/10 2:09 AM, Kevin Oberman wrote: I can find nothing in the documentation that states such. If I missed it, I'd appreciate someone pointing me at it. I have some vague memory of seeing messages to that effect when using it on a Solaris system in around 1999. I stopped using it around then and switched to host and dig. I can't point you to specific documentation (I stopped caring when I started using dig), but I did find these: http://cr.yp.to/djbdns/nslookup.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/nslookup-flaws.html As far as I'm aware it only hung around because it was available on Windows NT/2K/etc., while host and dig were not. ISC has tried to kill it, but the beast is resilient and won't die. Invocations of nslookup are embedded in thousands of legacy scripts and some folks are unable or unwilling to change them. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
Hello Kevin, Wed, 06 Oct 2010 07:47:41 -0700 Kevin Oberman wrote: I keep hoping for a BIND distro that upgrades nslookup(1) to: print STDERR, nslookup(1) has been replaced by host(1)\n; exit 0; Short answer: never. I've been wishing that nslookup would go away since back in BIND-v4 days. I could save a lot of troubleshooting time if I didn't get trouble reports based on the use of nslookup that is misleading or not completely bogus. What about any scripts and tools that rely on the expected behaviour and output of nslookup? Just think about the amount of such legacy and sometimes obsolete *but working* software. Who would be responsible for migration so the newer DNS tools would be used instead of nslookup? :) Note: I'm not talking about my own scripts and tools (I'm using dig and/or host whenever possible). -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
On 7/10/10 4:42 AM, Kevin Darcy wrote: ISC has tried to kill it, but the beast is resilient and won't die. Maybe we should call it a wombat then ... Invocations of nslookup are embedded in thousands of legacy scripts and some folks are unable or unwilling to change them. Nothing quite like coding/sysadmin laziness is there. Still, I probably can't talk on that front. Regards, Ben signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
Hello Kevin, Wed, 06 Oct 2010 13:42:35 -0400 Kevin Darcy wrote: ISC has tried to kill it, but the beast is resilient and won't die. Invocations of nslookup are embedded in thousands of legacy scripts and some folks are unable or unwilling to change them. Well said, Kevin! Just have sent some similar thoughts to the list. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.name/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Unable to query the nameserver
Of course some versions of nslookup arent' standard even for nslookup. The one on HP-UX actually interrogates local /etc/hosts file if nsswitch.conf says to use files first. I got so used to doing that for years that when I tried to use nslookup on Linux back in 2005 I was miffed because it was broken and only looked up from name servers. (Someone even had the gall to point out that nslookup was name server lookup). :-) -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Ben McGinnes Sent: Wednesday, October 06, 2010 1:52 PM To: Kevin Darcy Cc: bind-users@lists.isc.org Subject: Re: Unable to query the nameserver On 7/10/10 4:42 AM, Kevin Darcy wrote: ISC has tried to kill it, but the beast is resilient and won't die. Maybe we should call it a wombat then ... Invocations of nslookup are embedded in thousands of legacy scripts and some folks are unable or unwilling to change them. Nothing quite like coding/sysadmin laziness is there. Still, I probably can't talk on that front. Regards, Ben Proud partner. Susan G. Komen for the Cure. Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
non-24 bit subnets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings,
I'm setting up a new DNS server for internal use in the two
departments I support. Up until very recently, all our subnets have had
24 bit masks, which has made configuring bind very easy. However, we
now have three sizes, and may have more later: for right now, though,
it's 22, 24, and 25 bit. There are reasons for splitting things up that
way, some good, some bad, and all irrelevant to the discussion at hand.
The question is, how do I do it? Is there a simple way? With 24-bit,
I would define the files using:
zone 200.12.10.in-addr.arpa {
type master;
file /var/cache/bind/200.12.10.in-addr.arpa.zone;
};
zone test.chem.cns {
type master;
file /var/cache/bind/test.chem.cns.zone;
};
Then in 200.12.10.in-addr.arpa.zone hosts are defined with:
11 PTR test1.test.chem.cns.
and in test.chem.cns they're defined with:
test1 IN A 10.12.200.11
That works, and works reliably.
But how do I deal with larger or smaller subnets? Clearly I can't use
exactly the same notation, but I assume there has to be a way. If
anyone can even point me at some documentation, I'd appreciate it --
I've been looking for a few days, and everything I've found assumes a
/24 subnet.
Thanks,
Alex McKenzie
a...@chem.umass.edu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkysw1gACgkQWFYfIucpZ2OcagCcDqlti0H2j6QSY8nrBqt2NmSC
aH4AmgJUu/Ux8jOcY5wsV2xJWQgI3WoD
=o909
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
Date: Wed, 6 Oct 2010 14:03:56 -0400 From: Lightner, Jeff jlight...@water.com Sender: bind-users-bounces+oberman=es@lists.isc.org Of course some versions of nslookup arent' standard even for nslookup. The one on HP-UX actually interrogates local /etc/hosts file if nsswitch.conf says to use files first. I got so used to doing that for years that when I tried to use nslookup on Linux back in 2005 I was miffed because it was broken and only looked up from name servers. (Someone even had the gall to point out that nslookup was name server lookup). :-) -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Ben McGinnes Sent: Wednesday, October 06, 2010 1:52 PM To: Kevin Darcy Cc: bind-users@lists.isc.org Subject: Re: Unable to query the nameserver On 7/10/10 4:42 AM, Kevin Darcy wrote: ISC has tried to kill it, but the beast is resilient and won't die. Maybe we should call it a wombat then ... Invocations of nslookup are embedded in thousands of legacy scripts and some folks are unable or unwilling to change them. Nothing quite like coding/sysadmin laziness is there. Still, I probably can't talk on that front. Invocations of nslookup are embedded in thousands of BROKEN legacy scripts. nslookup is broken. It gives answers that are, from any sane point of view, wrong (though right from some other points of view). Most of the users of those legacy script are completely unaware of this until it bites them and they either kludge around the case they hit or fix the scripts to use host (or, very rarely, dig). Could we maybe replace nslookup(1) with a script which does a host(1) and and re-formats the output to look like nslookup(1) output. I don;t know that this would be easy, but it LOOKS like it would be easy. Yes, I am sure that some script somewhere depends on some wrong response from nslookup, but I can't see keeping nslookup(1) alive as is for that amazingly unlikely case. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
For larger subnets just use multiple zones as necessary. For 10.20.30.0/23 you have 30.20.10.in-addr.arpa and 31.20.10.in-addr.arpa. For smaller than a /24 look at RFC 2317. That's only necessary if you want to delegate authority to a different DNS server. If you have multiple networks in a /24, all of the rDNS entries for those networks can exist in a single zone. On Oct 6, 2010, at 1:43 PM, Alex McKenzie wrote: But how do I deal with larger or smaller subnets? Clearly I can't use exactly the same notation, but I assume there has to be a way. If anyone can even point me at some documentation, I'd appreciate it -- I've been looking for a few days, and everything I've found assumes a /24 subnet. -- Matt Baxter m...@fatpipe.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the quick reply, Matt. Unfortunately, we do have need -- or at least a use -- to have smaller subnets in multiple files, but without delegating authority. The problem is that some of those small subnets should have a shorter TTL, or other settings changed. If there's a way to change all the settings by host in a single file, that would at least make that easier. For larger subnets we can use multiple zones, but I'd hoped to avoid it if possible. It sounds from this like there isn't a way, though. Thanks, Alex Matt Baxter wrote: For larger subnets just use multiple zones as necessary. For 10.20.30.0/23 you have 30.20.10.in-addr.arpa and 31.20.10.in-addr.arpa. For smaller than a /24 look at RFC 2317. That's only necessary if you want to delegate authority to a different DNS server. If you have multiple networks in a /24, all of the rDNS entries for those networks can exist in a single zone. On Oct 6, 2010, at 1:43 PM, Alex McKenzie wrote: But how do I deal with larger or smaller subnets? Clearly I can't use exactly the same notation, but I assume there has to be a way. If anyone can even point me at some documentation, I'd appreciate it -- I've been looking for a few days, and everything I've found assumes a /24 subnet. -- Matt Baxter m...@fatpipe.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkysxzMACgkQWFYfIucpZ2PdoACeJv9m62wR5z2Msfcg+JOG7CEM gOUAnj1lE2pdbkeCZpTFmGLjd+kwA4Zp =QvDF -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
On Wed, 6 Oct 2010, Alex McKenzie wrote: Unfortunately, we do have need -- or at least a use -- to have smaller subnets in multiple files, but without delegating authority. The problem is that some of those small subnets should have a shorter TTL, or other settings changed. If there's a way to change all the settings by host in a single file, that would at least make that easier. You could use one real zone file which is referenced by named.conf, with $INCLUDE directives in that zone file to pull in the parts of the zone from files containing the subsets you want. A $TTL directive at the top of each small file should give you the variable TTL defaulting you want. For larger subnets we can use multiple zones, but I'd hoped to avoid it if possible. It sounds from this like there isn't a way, though. Right. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
On 10/6/2010 3:21 PM, Jay Ford wrote: On Wed, 6 Oct 2010, Alex McKenzie wrote: Unfortunately, we do have need -- or at least a use -- to have smaller subnets in multiple files, but without delegating authority. The problem is that some of those small subnets should have a shorter TTL, or other settings changed. If there's a way to change all the settings by host in a single file, that would at least make that easier. You could use one real zone file which is referenced by named.conf, with $INCLUDE directives in that zone file to pull in the parts of the zone from files containing the subsets you want. A $TTL directive at the top of each small file should give you the variable TTL defaulting you want. You can have a different TTL for each and every record, if you like, in the same zone file with no includes (the $TTL directive can appear multiple times). e.g. : $TTL 300; 5 mins *PTRhost-no-spec.example.com. $TTL 3600; 1 hour 17 PTR mail.example.com. $TTL 1800; 30 mins 18 PTR mail2.example.com. $TTL 86400; 1 day 19PTRwhatever.example.com 20PTRwhatever2.example.com 22PTRwhatever2.example.com ^^ This works for me. For larger subnets we can use multiple zones, but I'd hoped to avoid it if possible. It sounds from this like there isn't a way, though. Right. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- -___ David Miller Tiggee LLC dmil...@tiggee.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Miller wrote: On 10/6/2010 3:21 PM, Jay Ford wrote: On Wed, 6 Oct 2010, Alex McKenzie wrote: Unfortunately, we do have need -- or at least a use -- to have smaller subnets in multiple files, but without delegating authority. The problem is that some of those small subnets should have a shorter TTL, or other settings changed. If there's a way to change all the settings by host in a single file, that would at least make that easier. You could use one real zone file which is referenced by named.conf, with $INCLUDE directives in that zone file to pull in the parts of the zone from files containing the subsets you want. A $TTL directive at the top of each small file should give you the variable TTL defaulting you want. You can have a different TTL for each and every record, if you like, in the same zone file with no includes (the $TTL directive can appear multiple times). e.g. : $TTL 300; 5 mins *PTRhost-no-spec.example.com. $TTL 3600; 1 hour 17 PTR mail.example.com. $TTL 1800; 30 mins 18 PTR mail2.example.com. $TTL 86400; 1 day 19PTRwhatever.example.com 20PTRwhatever2.example.com 22PTRwhatever2.example.com ^^ This works for me. For larger subnets we can use multiple zones, but I'd hoped to avoid it if possible. It sounds from this like there isn't a way, though. Right. Interesting -- I'll keep that in mind. I suspect I can make either that or the INCLUDE directive work for me. Out of curiosity: what if it's a /16 or /8 network? Do those also get built as 24 bit files, or can they be built differently? I seem to recall seeing an option for a reverse lookup file with hosts declared as: x.y PTR host.domain.tld. Does that work, or was that an old format that's been deprecated, or would it never have worked? Thanks, Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkys2NoACgkQWFYfIucpZ2MowQCdEAnTH2n8Ylj2eanapBMXhXoI pEEAn2ePq2ykapSNVNKT2tiocxyKgAsm =70tZ -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
On Wed, 6 Oct 2010, Alex McKenzie wrote: Out of curiosity: what if it's a /16 or /8 network? Do those also get built as 24 bit files, or can they be built differently? I seem to recall seeing an option for a reverse lookup file with hosts declared as: x.y PTR host.domain.tld. Does that work, or was that an old format that's been deprecated, or would it never have worked? Sure, that works For the /16 case, define the zone like b.a.in-addr.arpa define records like d.c PTR name. for address a.b.c.d. For the /8 case, define the zone like a.in-addr.arpa define records like d.c.b PTR name. for address a.b.c.d. Note the order of the address components in the zone file, with least significant furthest left. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay Ford wrote: On Wed, 6 Oct 2010, Alex McKenzie wrote: Out of curiosity: what if it's a /16 or /8 network? Do those also get built as 24 bit files, or can they be built differently? I seem to recall seeing an option for a reverse lookup file with hosts declared as: x.yPTRhost.domain.tld. Does that work, or was that an old format that's been deprecated, or would it never have worked? Sure, that works For the /16 case, define the zone like b.a.in-addr.arpa define records like d.c PTR name. for address a.b.c.d. For the /8 case, define the zone like a.in-addr.arpa define records like d.c.b PTR name. for address a.b.c.d. Note the order of the address components in the zone file, with least significant furthest left. Got it. So basically bind can cope with a subnet that falls on an octet boundary, but not inside an octet. That's unfortunate for my purposes, but not unreasonable. Since we actually control the full /16 network (it's an internal NATed network), I may just build my files to match our actual subnets, then include them all this way. I suspect that will wind up with the best balance of human-readability to computer-readability. Thanks again to everyone who responded: I've had to learn DNS and bind as I went along, so there are some fairly large holes in my understanding. (Actually, my understanding is probably 99% holes, with a couple of threads stretching across where I've had to make something work) - -Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkys3zwACgkQWFYfIucpZ2NjJgCfbIT7qexrN50l67xp1BQP0vej nloAn0CtSCEPOCRzh5KY4lMKZLOl0F++ =UM3F -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
In message 4cacdf3c.9040...@chem.umass.edu, Alex McKenzie writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jay Ford wrote: On Wed, 6 Oct 2010, Alex McKenzie wrote: Out of curiosity: what if it's a /16 or /8 network? Do those also get built as 24 bit files, or can they be built differently? I seem to recall seeing an option for a reverse lookup file with hosts declared as: x.yPTRhost.domain.tld. Does that work, or was that an old format that's been deprecated, or would it never have worked? Sure, that works For the /16 case, define the zone like b.a.in-addr.arpa define records like d.c PTR name. for address a.b.c.d. For the /8 case, define the zone like a.in-addr.arpa define records like d.c.b PTR name. for address a.b.c.d. Note the order of the address components in the zone file, with least significant furthest left. Got it. So basically bind can cope with a subnet that falls on an octet boundary, but not inside an octet. That's unfortunate for my purposes, but not unreasonable. A better description is the DNS can cope . Basically it is a well known mapping from IP addresses in to the IN-ADDR.ARPA namespace. This mapping has no knowledge of the subnet boundaries. 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
Re: minimum cache times?
Hello, On 06.10.2010 01:16, Doug Barton wrote: If you would like to create a new thread your best bet is to store the list address in your e-mail address book and then create a new message to the list. By replying to someone else's message and changing the subject you cause your message to appear hidden behind the message you replied to for those of us who use threaded mail readers. Hehe. Thanks, I normally don't use threading, so I never noticed. Ok, so here's my recent reply again. Hope this is a new thread now, and apologies to those who see it the second time. On 05.10.2010 16:45, Nicholas Wheeler wrote: At Tue, 5 Oct 2010 09:19:49 -0400, Atkins, Brian (GD/VA-NSOC) wrote: From what I've read, everyone seems to frown on over-riding cache times, but I haven't seen any specifics as to why it's bad. Because it's a protocol violation, deliberately ignores the cache time set by the owner of the data, and is dangerous. Eg, you ask me for the address of my web server. I answer, saying that the answer is good for a week, after which you need to ask again because I might have changed something. Well, I was talking about minimum values, and, especially, a min-ncache-ttl, i.e. a minimum for negative caching. My point of view is that of a the operator of a very busy DNS resolver/cache infrastructure. For anecdotal evidence, I present this: http://blog.boxedice.com/2010/09/28/watch-out-for-millions-of-ipv6-dns--requests/ Now this ostensibly is about how bad IPv6 is for DNS (n comment), but somewhere down comes the interesting tidbit: apparently there are commercial DNS providers (dyn.com in this case) who recommend and default to 60 seconds as SOA value for negative caching in their customer zones. RIPE's recommended default is 1 hour. Of course they do this for a reason - they actually charge by request, so a badly set up customer DNS improves their bottom line. This is ridiculous and puts quite a strain on resolvers having to deal with such data - especially if one of 2 requests is no-error/no-data for reasons. So, if this is a trend, we might want to have a min-ncache-ttl of 300, just to get rid of the most obnoxious jerks. Same goes for positive caching; sensible minimum values used to be a matter of politeness, but folks like Akamai give us TTLs like 20 or 60. As long as Akamai is the only one doing this that's not a problem - but should that get widespread use I'd be inclined to clamp down on this, too. The TTL mechanism is part of the protocol for a reason: it's to control how tightly consistent the data are supposed to be in the opinion of the publisher of the data. Nobody but the publisher of the data has enough information to know how long it's safe to keep the data. Some publishers make silly decisions about this setting, which causes other problems, but keeping data past its expiration time is not the answer. Caching is part of the protocol, too. If there are large scale developments sabotaging that it forces me to have much more resolver capacity online. And that costs *me* money. Yes, publisher should know best - but apparently he often doesn't, and publishing bad DNS data affect's other people's systems, too. Regards Christoph Weber-Fahr ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: minimum cache times?
In message 4cad0856.9010...@arcor.de, Christoph Weber-Fahr writes: On 05.10.2010 16:45, Nicholas Wheeler wrote: At Tue, 5 Oct 2010 09:19:49 -0400, Atkins, Brian (GD/VA-NSOC) wrote: From what I've read, everyone seems to frown on over-riding cache times, but I haven't seen any specifics as to why it's bad. Because it's a protocol violation, deliberately ignores the cache time set by the owner of the data, and is dangerous. Eg, you ask me for the address of my web server. I answer, saying that the answer is good for a week, after which you need to ask again because I might have changed something. Well, I was talking about minimum values, and, especially, a min-ncache-ttl, i.e. a minimum for negative caching. My point of view is that of a the operator of a very busy DNS resolver/cache infrastructure. For anecdotal evidence, I present this: http://blog.boxedice.com/2010/09/28/watch-out-for-millions-of-ipv6-dns--r equests/ Now this ostensibly is about how bad IPv6 is for DNS (n comment), but somewhere down comes the interesting tidbit: apparently there are commercial DNS providers (dyn.com in this case) who recommend and default to 60 seconds as SOA value for negative caching in their customer zones. For a dynamic DNS provider where A RRsets come and go 60 seconds is about right. It's also pretty good evidence that it is time to set up IPv6 for that name. There are obviously plenty of clients out there willing to connect over IPv6 if only the server supported it. RIPE's recommended default is 1 hour. Aimed at a different user base. Of course they do this for a reason - they actually charge by request, so a badly set up customer DNS improves their bottom line. This is ridiculous and puts quite a strain on resolvers having to deal with such data - especially if one of 2 requests is no-error/no-data for reasons. So, if this is a trend, we might want to have a min-ncache-ttl of 300, just to get rid of the most obnoxious jerks. Or one might actually turn on IPv6. Plenty of unsatisfied demand out there. Same goes for positive caching; sensible minimum values used to be a matter of politeness, but folks like Akamai give us TTLs like 20 or 60. As long as Akamai is the only one doing this that's not a problem - but should that get widespread use I'd be inclined to clamp down on this, too. The TTL mechanism is part of the protocol for a reason: it's to control how tightly consistent the data are supposed to be in the opinion of the publisher of the data. Nobody but the publisher of the data has enough information to know how long it's safe to keep the data. Some publishers make silly decisions about this setting, which causes other problems, but keeping data past its expiration time is not the answer. Caching is part of the protocol, too. If there are large scale developments sabotaging that it forces me to have much more resolver capacity online. Well a little more bandwidth. Percentage wise DNS is small compared to all the other traffic out there. And that costs *me* money. Yes, publisher should know best - but apparently he often doesn't, and publishing bad DNS data affect's other people's systems, too. Regards Christoph Weber-Fahr -- 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
Response Times on Different Virtual Interfaces
I'm running BIND 9.6.1_P1. The server has multiple virtual interfaces that
BIND
listens on:
listen-on { 127.0.0.1; 172.30.0.213; 192.168.43.98; };
Sometimes I can get quite a huge difference in response time depending on which
virtual interface I query against. For example, most of our users use
172.30.0.213. When queries against it becomes slow, I can query against the
192.168.43.98 address and get reasonable response times. Is this a limitation
of BIND, the version of BIND I'm running, or a misconfiguration on my part?
Thanks for any tips or insights.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
