Multi language support in BIND
Hi, Can anyone tell me how to enable Arabic domain name query in BIND running Redhat RHEL 5. Actually we have many internal domain name zone configured in BIND running in Redhat 5 OS. Since i am from Middle east, users in my company wants to access their internal domain name through arabic name in Explorer. Is there any such option in BIND? Your response will help us to get customer satisfaction. Regards Papdheen M ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How to allow set Host file dns query priorities in BIND
Hi, Our setup is; We have internal DNS server wherein BIND is configured in RHEL 5 and many internal zones are configured. if Internet connection is down, our Internal DNS severs are not able to get the DNS query from ISP DNS server. Because of this, all users are not able to access many critical application hosted in internet. Now we would like to add those critical applicaton DNS entries in our internal DNS server HOST file. So that if internet link is down, users will be able to get the IP address of the URL through host file. is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? Thanks. babu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi script support in BIND
[I changed the subject, which seemed wrong to me.] On Wed, Feb 23, 2011 at 02:33:56PM +0530, babu dheen babudh...@yahoo.co.in wrote a message of 56 lines which said: Can anyone tell me how to enable Arabic domain name query in BIND running Redhat RHEL 5. You have absolutely nothing to do. Read http://en.wikipedia.org/wiki/Internationalized_domain_name to understand why. users in my company wants to access their internal domain name through arabic name in Explorer. I'm not sure for Microsoft IE. Is there any such option in BIND? No need. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
I was thinking this is most likely the network problem, so you'd better setup a good network with redundancy and high availability. 2011/2/23 babu dheen babudh...@yahoo.co.in is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? -- Free SmartDNS Hosting: http://DNSbed.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi language support in BIND
Can anyone tell me how to enable Arabic domain name query in BIND running
Redhat RHEL 5.
Actually we have many internal domain name zone configured in BIND
running in Redhat 5 OS. Since i am from Middle east, users in my company
wants to access their internal domain name through arabic name in
Explorer.
You should look into Internationalized Domain Names (IDN). I haven't had
to deal much with those myself, thankfully, but there's some information
in various RFCs. I think perhaps
http://en.wikipedia.org/wiki/Internationalized_domain_name might be a good
place to start as well.
I can't type arabic letters here, so I'll give an example in Norwegian
instead - the concept should be the same.
If I want BIND to serve the domain æøå-domene.no, I'll actually have to
convert that name into punycode and put the converted name
(xn---domene-dxai4p.no) into BIND:
zone xn---domene-dxai4p.no {
type master;
file master/xn---domene-dxai4p.no;
etc
};
If you want that domain to receive emails or serve web-traffic, you'll
most likely also have to use the punycode version of the domain name in
your configuration, unless your software is capable of hiding those
details from you.
Do keep in mind that certain software just won't handle these types of
domain names - for example I know of a couple of webmail solutions (both
commercial and open source) that just aren't capable of sending emails to
such domain names - unless you make your users send directly to the
punycode version - and really, you can't expect people to do that
manually.
Regards
Eivind Olsen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
On Wed, Feb 23, 2011 at 02:38:19PM +0530, babu dheen babudh...@yahoo.co.in wrote a message of 61 lines which said: if Internet connection is down, our Internal DNS severs are not able to get the DNS query from ISP DNS server. Because of this, all users are not able to access many critical application hosted in internet. I really do not understand. If the Internet connection is down, what use could be the Host file since users won't connect anyway? Now we would like to add those critical applicaton DNS entries in our internal DNS server HOST file. Very bad idea. A maintenance nightmare. Do you think that, six months from now, someone in your office will notice that Facebook changed its IP address and you have to update the Host file? So that if internet link is down, users will be able to get the IP address of the URL through host file. I don't think that the users want an IP address. They want a connection and, if the Internet link is down, getting the address won't help them. is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? Bad idea, don't do it. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: mx selection order
On Tue, Feb 22, 2011 at 04:37:03PM -0500, David Sparro dspa...@gmail.com wrote a message of 24 lines which said: it is up to the application how it will use the data. MX records are only used by MTA and, no, it is NOT up to the MTA to decide how to handle MX records, there is a standard for that, RFC 5321, section 5.1. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? No. BIND doesn't read/use the hosts file. What you _can_ do is configure BIND to believe it's authoritative for those zones, but I'd not recommend doing this unless you have a very good reason. And if your Internet connection goes down, does it really matter whether you can do lookups, if you can't make the connections anyway? Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Help on recursive set up
Hi, Could you please tell me how to set up for recursive server for NS delegation records. It would be great if you give named.conf Thanks Regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help on recursive set up
On 23.02.11 17:59, rams wrote: Could you please tell me how to set up for recursive server for NS delegation records. for recursive server or for NS delegation? It would be great if you give named.conf there's at least one default named.conf provided within bind installation in any package distribution, even if you compile from source. -- 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. LSD will make your ECS screen display 16.7 million colors ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help on recursive set up
On Wed, Feb 23, 2011 at 05:59:06PM +0530, rams brames...@gmail.com wrote a message of 33 lines which said: Could you please tell me how to set up for recursive server for NS delegation records. It would be great if you give named.conf It would be great if you rewrite your requirments because I simply cannot parse them. Enabling recursion: recursion yes; in named.conf. But I do not understand the point about NS delegation records. Please elaborate. ___ 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: Help on recursive set up
I have configuered recursion yes in named.conf and i queried for NS delegated records against bind. Actually that domain is not exist in my system. Here how bind will work. On Wed, Feb 23, 2011 at 6:20 PM, rams brames...@gmail.com wrote: I have configuered recursion yes in named.conf and i queried for NS delegated records against bind. Actually that domain is not exist in my system. Here how bind will work. On Wed, Feb 23, 2011 at 6:16 PM, Stephane Bortzmeyer bortzme...@nic.frwrote: On Wed, Feb 23, 2011 at 05:59:06PM +0530, rams brames...@gmail.com wrote a message of 33 lines which said: Could you please tell me how to set up for recursive server for NS delegation records. It would be great if you give named.conf It would be great if you rewrite your requirments because I simply cannot parse them. Enabling recursion: recursion yes; in named.conf. But I do not understand the point about NS delegation records. Please elaborate. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help on recursive set up
On Wed, Feb 23, 2011 at 06:45:11PM +0530, rams brames...@gmail.com wrote a message of 104 lines which said: I have configuered recursion yes in named.conf and i queried for NS delegated records against bind. Actually that domain is not exist in my system. Here how bind will work. To tell the truth, I do not really understand the last two sentences. It is probably because English is not my mother language. I suggest that you post dig's output, anyone can understand it, irrespective of the language they were trained in :-) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
root zone initial key in bind.keys
Hello, after downloading and unpacking bind9.7.3, there's bind.keys file that contains this comment: # This file also contains a copy of the trust anchor for the DNS root zone # (.). However, named does not use it; it is provided here for # informational purposes only. To switch on DNSSEC validation at the # root, the root key below can be copied into named.conf. Does this still apply? Do I really have to copy the key for . into bind.conf in order for it to be used and it's not managed automatically? Or did I misunderstand something here? -- 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. WinError #9: Out of error messages. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message 0539E64AD2B54AD2804C2394F923800B@se179, Shaoquan Lin writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; DiG 9.6.0-APPLE-P2 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/e2ZhB3h944kpymqL ag3tCg== ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 187 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:54:06 2011 ;; MSG SIZE rcvd: 574 2) Older version of Binds (like 9.3) seems able to resolve vwall4a.nyc.gov as shown the packets I captured in my previous e-mail. What options in named.conf I can use to set tc? Thank you. Shaoquan Lin -- Shaoquan Lin, Computer Systems Manager School of Engineering, City College of New York Phone: (212) 650 6762 Fax: (212) 650 5768 E-mail: l...@ccny.cuny.edu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Security Advisory: Server Lockup Upon IXFR or DDNS Update Combined with High Query Rate
On Feb 22, 2011, at 3:55 PM, Larissa Shapiro wrote: Description and Impact: When an authoritative server processes a successful IXFR transfer or a dynamic update, there is a small window of time during which the IXFR/update coupled with a query may cause a deadlock to occur. This deadlock will cause the server to stop processing all requests. A high query rate and/or a high update rate will increase the probability of this condition. Does the authoritative server that processes an IXFR transfer refer to: a) the IXFR server? b) the IXFR client? c) both? Thanks, Dave Coulthart ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest On 02/23/2011 11:15 AM, Shaoquan Lin wrote: Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message 0539E64AD2B54AD2804C2394F923800B@se179, Shaoquan Lin writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; DiG 9.6.0-APPLE-P2 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov.INA ;; AUTHORITY SECTION: nyc.gov.86400INNSvwall1a.nyc.gov. nyc.gov.86400INNSvwall2a.nyc.gov. nyc.gov.86400INNSvwall3a.nyc.gov. nyc.gov.86400INNSvwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/e2ZhB3h944kpymqL ag3tCg== ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400INA161.185.1.3 vwall2a.nyc.gov.86400INA161.185.1.12 vwall3a.nyc.gov.86400INA167.153.130.12 vwall4a.nyc.gov.86400INA167.153.130.13 ;; Query time: 187 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:54:06 2011 ;; MSG SIZE rcvd: 574 2) Older version of Binds (like 9.3) seems able to resolve vwall4a.nyc.gov as shown the packets I captured in my previous e-mail. What options in named.conf I can use to set tc? Thank you. Shaoquan Lin - -- - _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$| |__| | | |__/ |
Re: root zone initial key in bind.keys
# This file also contains a copy of the trust anchor for the DNS root zone # (.). However, named does not use it; it is provided here for # informational purposes only. To switch on DNSSEC validation at the # root, the root key below can be copied into named.conf. Does this still apply? Do I really have to copy the key for . into bind.conf in order for it to be used and it's not managed automatically? Or did I misunderstand something here? It still applies in 9.7.3. In 9.8 (the first release of which should be published within a week, barring unexpected problems), we added the option dnssec-validation auto, which turns on the root key automatically. But in 9.7, the only key named pulls out of bind.keys is the one for dlv.isc.org (and it reads that one only if you turn on dnssec-lookaside auto). The dnssec-validation auto feature isn't going to be backported to 9.7, but we thought it would still be useful for people to have a copy of the root key included somewhere in the tarball, so we put the key into both branches, but with different comments. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root zone initial key in bind.keys
On Feb 23 2011, Matus UHLAR - fantomas wrote: Hello, after downloading and unpacking bind9.7.3, there's bind.keys file that contains this comment: # This file also contains a copy of the trust anchor for the DNS root zone # (.). However, named does not use it; it is provided here for # informational purposes only. To switch on DNSSEC validation at the # root, the root key below can be copied into named.conf. Does this still apply? Do I really have to copy the key for . into bind.conf in order for it to be used and it's not managed automatically? Or did I misunderstand something here? Experiment reveals that, *provided* you use dnssec-lookaside auto;, BIND uses both entries in the managed-keys statement in [prefix]/etc/bind.keys. In fact, the documentation in the file is not consistent. Apart from the bit you quote, there is also this # ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml # for current trust anchor information. # NOTE: This key is activated by setting dnssec-validation auto; # in named.conf. just before the root key itself, which contradicts the former (and appears to be true!). Personally, on production servers, I would rather not rely on what ISC are doing with this file, but have my own managed-keys statement and avoid dnssec-lookaside auto;. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root zone initial key in bind.keys
On Feb 23 2011, Evan Hunt wrote: # This file also contains a copy of the trust anchor for the DNS root zone # (.). However, named does not use it; it is provided here for # informational purposes only. To switch on DNSSEC validation at the # root, the root key below can be copied into named.conf. Does this still apply? Do I really have to copy the key for . into bind.conf in order for it to be used and it's not managed automatically? Or did I misunderstand something here? It still applies in 9.7.3. In 9.8 (the first release of which should be published within a week, barring unexpected problems), we added the option dnssec-validation auto, which turns on the root key automatically. But in 9.7, the only key named pulls out of bind.keys is the one for dlv.isc.org (and it reads that one only if you turn on dnssec-lookaside auto). That may have been the intent, but I can assure you that it isn't what actually happens! To make doubly sure, I stopped the test 9.7.3 named on my workstation, removed the managed-keys.bind* files as well, and restarted it with a named.conf with no managed-keys statement but with dnssec-lookaside auto. It ends up with trust anchors for both the root and dlv.isc.org, as shown by all of * rndc secroots * what appears in managed-keys.bind * ad bit on appropriate dig +dnssec calls which sort of convinces me ... :-) -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root zone initial key in bind.keys
That may have been the intent, but I can assure you that it isn't what actually happens! Whoops. You're right, and it's a bug. The keys aren't read without dnssec-lookaside auto being turned on, but if it is, then both keys are loaded. This works correctly in 9.8, but a little piece of code that was supposed to have been committed to 9.7 seems to have been left out by mistake. My apologies; apparently we've made some people's systems more secure than we intended. :/ If anyone is out there who wants to be using ISC DLV but does not want to use the root key, comment the root key out of bind.keys. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
On 2/23/2011 4:08 AM, babu dheen wrote: Hi, Our setup is; We have internal DNS server wherein BIND is configured in RHEL 5 and many internal zones are configured. if Internet connection is down, our Internal DNS severs are not able to get the DNS query from ISP DNS server. Because of this, all users are not able to access many critical application hosted in internet. Now we would like to add those critical applicaton DNS entries in our internal DNS server HOST file. So that if internet link is down, users will be able to get the IP address of the URL through host file. If the names of these critical applications reside in zones that you own, you should probably set yourself up as a stealth slave for those zones. If they're in someone else's zones, and being a stealth slave is impractical, then you could play a dangerous game by maintaining a fake version of the zone yourself (defined as master). Dangerous because the IPs could change without any notice and then your data is instantly invalid. But, I suppose that isn't any worse than hosts-file entries, right? is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? Nope, BIND doesn't control whether a process looks in the hosts file or not. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
[forgot to change the digest subject before sending - sorry folks] On Wed, Feb 23, 2011 at 12:30, Christopher Cain ch...@christophercain.cawrote: Ryan - thanks for the link. This would have saved me quite a bit of troubleshooting time a few weeks back. Christopher Cain E: ch...@christophercain.ca -- Forwarded message -- From: Ryan Novosielski novos...@umdnj.edu To: bind-users@lists.isc.org Date: Wed, 23 Feb 2011 11:39:41 -0500 Subject: Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
On 2/23/2011 4:57 AM, Eivind Olsen wrote: is there any option in BIND to give priority to HOST file before connecting it to internet ISP or local zone? No. BIND doesn't read/use the hosts file. What you _can_ do is configure BIND to believe it's authoritative for those zones, but I'd not recommend doing this unless you have a very good reason. And if your Internet connection goes down, does it really matter whether you can do lookups, if you can't make the connections anyway? I hear that reasoning a lot, but it's actually a fallacy. Some applications/subsystems differentiate between host not found errors (considered permanent) and cannot connect errors (considered temporary and retryable). In fact, those might be very different code paths, and the app/subsystem behavior might differ wildly. Unless one intimately knows the failure behavior of *every*single*app*and*subsystem* in one's environment (which in a large/complex environment is a constantly moving target, since new apps and subsystems are being implemented all the time), one should err on the side of safety and ensure that DNS resolution still works even if the resources that the address (A/) records point to is unavailable. One should also bear in mind that DNS isn't only used for obtaining address records for purposes of immediate client/server connection. Data mining, resource location, and general information retrieval functions are often implemented in DNS, and the availability of these functions shouldn't necessarily be made dependent on the up/down status of some arbitrary network link. It's also possible that an app could make a lookup, and as long as the TTL on the records hasn't expired, legitimately attempt a connection at some _later_ time. Not everything is on-demand. To answer the original poster's question: BIND doesn't control whether a process uses the hosts file for its lookup or not, that's usually an OS-configuration thing (see, e.g. http://en.wikipedia.org/wiki/Name_Service_Switch, http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/netsvc.conf.htm, etc.) - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root zone initial key in bind.keys
Date: Wed, 23 Feb 2011 17:32:44 + From: Evan Hunt e...@isc.org Sender: bind-users-bounces+oberman=es@lists.isc.org That may have been the intent, but I can assure you that it isn't what actually happens! Whoops. You're right, and it's a bug. The keys aren't read without dnssec-lookaside auto being turned on, but if it is, then both keys are loaded. This works correctly in 9.8, but a little piece of code that was supposed to have been committed to 9.7 seems to have been left out by mistake. My apologies; apparently we've made some people's systems more secure than we intended. :/ If anyone is out there who wants to be using ISC DLV but does not want to use the root key, comment the root key out of bind.keys. I would really hoe that the set described above is an empty set. I can imagine some reasons some might want to do it, but I can't come up with a GOOD reason for it. Most people move their trust anchors out of the DLV when they are confident that the keys are properly located in the parent zone. In other words, I think that this should be considered a feature and not a bug. -- 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: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A couple more gems: https://www.dnssec-deployment.org/wp-content/uploads/2010/03/DNSSEC-CPE-Report.pdf (really anything at dnssec-deployment.org) There was another table that I found someplace and cannot find now that listed Cisco PIX and mentioned with a * the subtle difference between versions of that firewall firmware. I can't find that table anywhere -- was HTML, not in a PDF. On 02/23/2011 11:39 AM, Ryan Novosielski wrote: Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest On 02/23/2011 11:15 AM, Shaoquan Lin wrote: Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message 0539E64AD2B54AD2804C2394F923800B@se179, Shaoquan Lin writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; DiG 9.6.0-APPLE-P2 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov.INA ;; AUTHORITY SECTION: nyc.gov.86400INNSvwall1a.nyc.gov. nyc.gov.86400INNSvwall2a.nyc.gov. nyc.gov.86400INNSvwall3a.nyc.gov. nyc.gov.86400INNSvwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/e2ZhB3h944kpymqL ag3tCg== ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400INA161.185.1.3 vwall2a.nyc.gov.86400INA161.185.1.12 vwall3a.nyc.gov.86400INA167.153.130.12 vwall4a.nyc.gov.86400INA167.153.130.13 ;; Query time: 187 msec ;; SERVER:
Re: How to allow set Host file dns query priorities in BIND
Den 23. feb. 2011 kl. 18:19 skrev Kevin Darcy k...@chrysler.com: One should also bear in mind that DNS isn't only used for obtaining address records for purposes of immediate client/server connection. ...etc... Fair enough. I didn't see any mention of that in the original posting, and I don't think the hosts file is very suited for LOC, TXT and other such records. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to allow set Host file dns query priorities in BIND
On 2/23/2011 12:19 PM, Kevin Darcy wrote: On 2/23/2011 4:57 AM, Eivind Olsen wrote: reason. And if your Internet connection goes down, does it really matter whether you can do lookups, if you can't make the connections anyway? I hear that reasoning a lot, but it's actually a fallacy. Some applications/subsystems differentiate between host not found errors (considered permanent) and cannot connect errors (considered temporary and retryable). In fact, those might be very different code paths, and the app/subsystem behavior might differ wildly. An app that treats can't get an answer the same as the answer is 'it doesn't exist' is doing something wrong. Although I guess I'm not trying to say that those apps don't exist. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: mx selection order
On 2/23/2011 4:56 AM, Stephane Bortzmeyer wrote: On Tue, Feb 22, 2011 at 04:37:03PM -0500, David Sparrodspa...@gmail.com wrote a message of 24 lines which said: it is up to the application how it will use the data. MX records are only used by MTA and, no, it is NOT up to the MTA to decide how to handle MX records, there is a standard for that, RFC 5321, section 5.1. Yes, but according to the RFC there is room for the MTA to make some administrative decisions on which MX records to use: However, there MAY also be a configurable limit on the number of alternate addresses that can be tried and If there are multiple destinations with the same preference and there is no clear reason to favor one ... I'll bet that different MTAs have different definitions of 'clear reason.' and Although the capability to try multiple alternative addresses is required, specific installations may want to limit or disable the use of alternative addresses. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
In PIX versions 6.3.2 and below you had to do: fixup protocol dns maximum-length 4096 In later versions you need: policy-map type inspect dns preset_dns_map parameters message-length maximum 4096 or to increase the response size length: policy-map global_policy class inspection_default inspect dns maximum-length 4096 This is rumor and innuendo, I personally believe that: a: firewalls with ALGs are the devil b: this goes double for PIX / ASA and c: doubled again for putting them in front of servers, especially DNS servers W On Feb 23, 2011, at 1:13 PM, Ryan Novosielski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A couple more gems: https://www.dnssec-deployment.org/wp-content/uploads/2010/03/DNSSEC-CPE-Report.pdf (really anything at dnssec-deployment.org) There was another table that I found someplace and cannot find now that listed Cisco PIX and mentioned with a * the subtle difference between versions of that firewall firmware. I can't find that table anywhere -- was HTML, not in a PDF. On 02/23/2011 11:39 AM, Ryan Novosielski wrote: Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest On 02/23/2011 11:15 AM, Shaoquan Lin wrote: Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message 0539E64AD2B54AD2804C2394F923800B@se179, Shaoquan Lin writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; DiG 9.6.0-APPLE-P2 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov.INA ;; AUTHORITY SECTION: nyc.gov.86400INNSvwall1a.nyc.gov. nyc.gov.86400INNSvwall2a.nyc.gov. nyc.gov.86400INNSvwall3a.nyc.gov. nyc.gov.86400INNSvwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8
Re: Help on recursive set up
There are multiple ways to interpret that question. Normally, a resolver either uses recursion (with a preconfigured set of forwarders) at a given point in resolving a particular name, or it follows the NS records in a delegation chain, non-recursively, in order to find the answer. It wouldn't do *both*. A given query can't be recursive and non-recursive at the same time. Possibly you are asking if it's possible for a nameserver which is delegated for a particular zone, to forward all queries for names in that zone to some other (private/internal) nameserver for resolution. The answer to that is no, since the queries being received by that visible nameserver are expected to be *non-recursive*, and non-recursive queries are never supposed to be forwarded anywhere. You might, however, look into some sort of DNS proxy solution, if this is what you're trying to accomplish. - Kevin On 2/23/2011 7:29 AM, rams wrote: Hi, Could you please tell me how to set up for recursive server for NS delegation records. It would be great if you give named.conf Thanks Regards, Ramesh ___ 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: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
There was also a message-length client auto or something like that too for some versions of some Cisco HW, but if memory serves, the version that introduced it is broken. :) On 02/23/2011 04:54 PM, Warren Kumari wrote: In PIX versions 6.3.2 and below you had to do: fixup protocol dns maximum-length 4096 In later versions you need: policy-map type inspect dns preset_dns_map parameters message-length maximum 4096 or to increase the response size length: policy-map global_policy class inspection_default inspect dns maximum-length 4096 This is rumor and innuendo, I personally believe that: a: firewalls with ALGs are the devil b: this goes double for PIX / ASA and c: doubled again for putting them in front of servers, especially DNS servers W On Feb 23, 2011, at 1:13 PM, Ryan Novosielski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A couple more gems: https://www.dnssec-deployment.org/wp-content/uploads/2010/03/DNSSEC-CPE-Report.pdf (really anything at dnssec-deployment.org) There was another table that I found someplace and cannot find now that listed Cisco PIX and mentioned with a * the subtle difference between versions of that firewall firmware. I can't find that table anywhere -- was HTML, not in a PDF. On 02/23/2011 11:39 AM, Ryan Novosielski wrote: Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest On 02/23/2011 11:15 AM, Shaoquan Lin wrote: Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; DiG 9.6.1-P3 +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov. 86400 IN NS vwall1a.nyc.gov. nyc.gov. 86400 IN NS vwall2a.nyc.gov. nyc.gov. 86400 IN NS vwall3a.nyc.gov. nyc.gov. 86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov. 86400 IN A 161.185.1.3 vwall2a.nyc.gov. 86400 IN A 161.185.1.12 vwall3a.nyc.gov. 86400 IN A 167.153.130.12 vwall4a.nyc.gov. 86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message 0539E64AD2B54AD2804C2394F923800B@se179, Shaoquan Lin writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; DiG 9.6.0-APPLE-P2 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov. 86400 IN NS vwall1a.nyc.gov. nyc.gov. 86400 IN NS vwall2a.nyc.gov. nyc.gov. 86400 IN NS vwall3a.nyc.gov. nyc.gov. 86400 IN NS vwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA
incorrect dns returned by public servers for our domain
Hi. When I query my dns servers internally and directly from outside I get [macgre@topnz15209-linux ~]$ dig @202.a.x.y mydomain.nz ; DiG 9.7.2-P3-RedHat-9.7.2-1.P3.fc13 @202.a.x.y mydomain.nz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2997 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;mydomain.nz. IN A ;; ANSWER SECTION: mydomain.nz.86400 IN A 202.a.t.z ;; AUTHORITY SECTION: mydomain.nz.86400 IN NS mcvpdns01.mydomain.nz. mydomain.nz.86400 IN NS drvpdns01.mydomain.nz. ;; ADDITIONAL SECTION: drvpdns01.mydomain.nz. 86400 IN A 202.a.x.z mcvpdns01.mydomain.nz. 86400 IN A 202.a.x.y ;; Query time: 2 msec ;; SERVER: 202.a.x.y#53(202.a.x.y) ;; WHEN: Thu Feb 24 11:39:26 2011 When I query against opendns and google's public servers I get [macgre@topnz15209-linux ~]$ dig @8.8.8.8 mydomain.nz ; DiG 9.7.2-P3-RedHat-9.7.2-1.P3.fc13 @8.8.8.8 mydomain.nz ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45766 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mydomain.nz. IN A ;; ANSWER SECTION: mydomain.nz.61371 IN A 202.a.t.z ;; Query time: 170 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Feb 24 11:41:32 2011 ;; MSG SIZE rcvd: 55 why are ;; AUTHORITY SECTION: mydomain.nz.86400 IN NS mcvpdns01.mydomain.nz. mydomain.nz.86400 IN NS drvpdns01.mydomain.nz. missing ? We a have users complaining that they cant resolve out dns servers, and thus can't do lookups for services. Our version of bind is 9.3.6-4.P1.el5_5.3 Thanks G ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
On 23/02/2011 23:53, Gregory Machin wrote: Hi Gregory, why are ;; AUTHORITY SECTION: mydomain.nz. 86400 IN NS mcvpdns01.mydomain.nz. mydomain.nz. 86400 IN NS drvpdns01.mydomain.nz. missing ? Google DNS and OpenDNS are meant to be used by end-users, who don't need the extra information in the authority section. The authority section is only needed by recursive resolvers. We a have users complaining that they cant resolve out dns servers, and thus can't do lookups for services. I actually doubt if the difference in response from Google/OpenDNS is responsible for resolution failures. It would be far more helpful if you can actually provide your domain name. Then someone can have a look and see if there's any obvious configuration issue. Without knowing the actual domain name, one can only guess about possible problems. Anand Buddhdev RIPE NCC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
Hi. Thanks for the feedback. I was warned not to provide to much info by the security guy. The domain name in question is openpolytechnic.ac.nz Thanks On Thu, Feb 24, 2011 at 12:36 PM, Anand Buddhdev ana...@ripe.net wrote: On 23/02/2011 23:53, Gregory Machin wrote: Hi Gregory, why are ;; AUTHORITY SECTION: mydomain.nz. 86400 IN NS mcvpdns01.mydomain.nz. mydomain.nz. 86400 IN NS drvpdns01.mydomain.nz. missing ? Google DNS and OpenDNS are meant to be used by end-users, who don't need the extra information in the authority section. The authority section is only needed by recursive resolvers. We a have users complaining that they cant resolve out dns servers, and thus can't do lookups for services. I actually doubt if the difference in response from Google/OpenDNS is responsible for resolution failures. It would be far more helpful if you can actually provide your domain name. Then someone can have a look and see if there's any obvious configuration issue. Without knowing the actual domain name, one can only guess about possible problems. Anand Buddhdev RIPE NCC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
Further to my private message, is your border router using bogon filters? I can actually get your local NS's using a U.S host on an old IP, but not from my connection, this suggests an outdated bogon filter since i'm on 27.x IP range. On Thu, 2011-02-24 at 15:00 +1300, Gregory Machin wrote: Hi. Thanks for the feedback. I was warned not to provide to much info by the security guy. signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
Hi. Thanks for the support and assitance. I see that the issue is related to the bogon filter in bind configuration. Where can I get a valid bogon list . Thanks On Thu, Feb 24, 2011 at 3:45 PM, Noel Butler noel.but...@ausics.net wrote: Further to my private message, is your border router using bogon filters? I can actually get your local NS's using a U.S host on an old IP, but not from my connection, this suggests an outdated bogon filter since i'm on 27.x IP range. On Thu, 2011-02-24 at 15:00 +1300, Gregory Machin wrote: Hi. Thanks for the feedback. I was warned not to provide to much info by the security guy. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
Hi, You can pretty much remove the entire statement now, as all /8's are issued as of about two weeks ago. (Confirming, with my 27.x IP I can now get answers from your local NS's so all looks good) Cheers On Thu, 2011-02-24 at 17:04 +1300, Gregory Machin wrote: Hi. Thanks for the support and assitance. I see that the issue is related to the bogon filter in bind configuration. Where can I get a valid bogon list . Thanks signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
https://blue-labs.org/software/dns/bogon-update.py -david On 02/23/11 23:04, Gregory Machin wrote: Hi. Thanks for the support and assitance. I see that the issue is related to the bogon filter in bind configuration. Where can I get a valid bogon list . Thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
On 24/02/2011 04:14, Noel Butler wrote:
You can pretty much remove the entire statement now, as all /8's are
issued as of about two weeks ago.
This works for me:
lucid-nonsense:~/src/namedb:% cat acl-ipv4-bogons.conf
// @(#) $Id: acl-ipv4-bogons.conf 800 2011-02-03 20:22:12Z matthew $
//
// Networks listed by IANA as test, RFC 1918, Multicast, Experimental,
// etc. (RFC 5735)
//
// See: http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
acl ipv4-bogons {
0.0.0.0/8;
10.0.0.0/8;
127.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.0.0.0/24;
192.0.2.0/24;
192.168.0.0/16;
198.18.0.0/15;
198.51.100.0/24;
203.0.113.0/24;
224.0.0.0/3;
};
//
// That's All Folks!
//
All of which are special purpose networks listed in RFC 5735 which you
shouldn't be seeing any DNS query traffic from on the open internet.
This bogon list is going to be static for the foreseeable future.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: incorrect dns returned by public servers for our domain
On 2/24/2011 1:19 AM, Matthew Seaman wrote:
On 24/02/2011 04:14, Noel Butler wrote:
You can pretty much remove the entire statement now, as all /8's are
issued as of about two weeks ago.
This works for me:
lucid-nonsense:~/src/namedb:% cat acl-ipv4-bogons.conf
// @(#) $Id: acl-ipv4-bogons.conf 800 2011-02-03 20:22:12Z matthew $
//
// Networks listed by IANA as test, RFC 1918, Multicast, Experimental,
// etc. (RFC 5735)
//
// See: http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
acl ipv4-bogons {
0.0.0.0/8;
10.0.0.0/8;
127.0.0.0/8;
169.254.0.0/16;
172.16.0.0/12;
192.0.0.0/24;
192.0.2.0/24;
192.168.0.0/16;
198.18.0.0/15;
198.51.100.0/24;
203.0.113.0/24;
224.0.0.0/3;
};
//
// That's All Folks!
//
All of which are special purpose networks listed in RFC 5735 which you
shouldn't be seeing any DNS query traffic from on the open internet.
This bogon list is going to be static for the foreseeable future.
+ 192.88.99.0/24 // 6to4 relay anycast - can be destination of packets,
*should* never be source
+ 240.0.0.0/4 // reserved for future use - likely to *never* be valid
source - I block, YMMV
-DM
Cheers,
Matthew
___
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
