Re: UAE punycode in zone
On 09/05/2010 19:31, Warren Kumari wrote: I am *so* not an IDN person (although I did follow the IDNA WG for a while), but I *believe* that the process is just to convert the native UTF8 representation (تامايدوجان.سى) to punycode (xn--mgbaajmr6mmaps.xn--ygb8b). There are a bunch of tools that will do this for you, I suspect that just using something like: http://mct.verisign-grs.com/conversiontool/convertServlet?input=تامايدوجان.سىtype=UTF8 is easiest. Now that you have the punycode representation, you just treat it like any other domain (create a zone file called xn--mgbaajmr6mmaps.xn--ygb8b, set $ORIGIN xn--mgbaajmr6mmaps.xn--ygb8b., etc). I sent a requests to isc for a new option in dig, enabled by default:- +[no]idn automatically convert input to IDN So entering:- dig تامايدوجان.سى would give you the result as if you had entered:- dig xn--mgbaajmr6mmaps.xn--ygb8b ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC website down
It is sod's law that just when I need to look up the email address to report a bug, currently the website is showing:- Unable to connect to database server [..] The MySQL error was: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2). [..] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC website down
It is back now. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate.exe and IPv6
On 23/11/09 11:15, Cathy Almond wrote: Chris - thanks for this - we've picked it up and made a bug report ourselves. But for future reference, our BIND mailing addresses are summarised here: https://www.isc.org/software/bind/news Cathy Thanks Cathy! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding updates between views
On 23/11/09 18:05, Chris Buxton wrote: The internal-in view should have some log entry of the forwarded update. I'm not sure what category or severity level that would be, though. I could not find it in either the query log or the update log. Bug? Of course, if you were to start using signed updates (either TSIG or GSS-TSIG), you would know what key was used. The purpose is to provide a free ipv6-only playground that anyone may use. Normal updates from external clients are logged as intended. Feel free to add, modify or remove records under dyn.ipv6.chaz6.com. When security is required I do of course use keys! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding updates between views
On 22/11/09 21:01, Chris Buxton wrote:
Change the zone from type forward to type slave, and add
allow-update-forwarding.
zone dyn.example.com. {
type slave;
masters { ::1; };
allow-update-forwarding { local-networks; };
};
Then in the external-in view, change allow-update to:
allow-update { ::1; };
Great, works like a charm... but... the update log only records ::1 as
the source and not the original address. Is it possible to keep that?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
nsupdate.exe and IPv6
Hi It seems nsupdate.exe in 9.6.1-P1 does not properly locate IPv6 nameservers. C:\Temp\bind-9.6.1-P1dig +short ns-v6-1.chaz6.com. in 2001:16d8:dd22:38::2 2001:16d8:ee0f:38::2 C:\Temp\bind-9.6.1-P1nsupdate server 2001:16d8:dd22:38::2 update add localhost.dyn.ipv6.chaz6.com. 7200 IN :: quit C:\Temp\bind-9.6.1-P1nsupdate update delete localhost.dyn.ipv6.chaz6.com. couldn't get address for 'ns-v6-1.chaz6.com': not found The same works fine from Linux:- $ rpmquery --whatprovides `which nsupdate` bind-utils-9.6.1P1-4.1.i586 $ nsupdate update add localhost.dyn.ipv6.chaz6.com. 7200 IN ::1 update delete localhost.dyn.ipv6.chaz6.com. quit Regards, Chris P.S. Is there a proper bug reporting address? I could not find it on the website. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse DNS Dig returning PTR results only with trace option
On 10/11/09 18:25, Raj Adhikari wrote: Now I can do a dig for an hour or so. But again I run into same problem. It wont return PTR record unless I explicitly do dig on ns1.cyzap.net. Also, the last did showing ns1.cyzap.net as Authority NS for this IP. But trace showing ns1.moneytreesystems.com as final sender. Could someone shed a light on this? 254.63.in-addr.arpa.86400 IN NS NS3.MCLEODUSA.NET. 254.63.in-addr.arpa.86400 IN NS NS1.MCLEODUSA.NET. 254.63.in-addr.arpa.86400 IN NS NS2.MCLEODUSA.NET. ;; Received 112 bytes from 192.42.93.32#53(y.arin.net) in 173 ms 228.134.254.63.in-addr.arpa. 7200 INNS ns1.cyzap.net. 228.134.254.63.in-addr.arpa. 7200 INNS ns2.cyzap.net. ;; Received 90 bytes from 209.253.113.19#53(NS3.MCLEODUSA.NET) in 159 ms 228.134.254.63.in-addr.arpa. 3600 INNS ns2.moneytreesystems.com. 228.134.254.63.in-addr.arpa. 3600 INNS ns1.moneytreesystems.com. ;; BAD (HORIZONTAL) REFERRAL ;; Received 160 bytes from 64.253.181.53#53(ns2.cyzap.net) in 167 ms You should not chain a delegation in this manner. Either make the servers ns1.cyzap.net. and ns2.cyzap.net. authoritative for 228.134.254.63.in-addr.arpa. or have your ISP change the NS records to point directly to ns1.moneytreesystems.com. and ns2.moneytreesystems.com. The cyzap servers do not respond with the authority bit set (aa in dig). Regards, Chris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to upgrade
On 23/08/09 08:23, sasa sasa wrote: Hi List, I want to know how to upgrade from BIND 9.4.2 to latest version? Thanks. Blue Blue Please see the following url for obtaining BIND:- https://www.isc.org/software/bind/getting You should have the least trouble upgrading to 9.4.3-P3 however the latest version is 9.6.1-P1. If you rely on a package mechanism you will need to contact the repository maintainer. Regards, Chris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegating reverse DNS to a customer
On 18/08/09 15:55, Ben Bridges wrote: Since the CIDR block you have been allocated containing 63.250.251.0/24 is smaller than a /16, ARIN is delegating authority for the IN-ADDR.ARPA zones for each of your /24's directly to your dns servers. In order for your customer's dns servers to be authoritative for 251.250.63.IN-ADDR.ARPA, you're going to have to have ARIN delegate the zone to your customer's servers. If you have not already SWIP'ed the /24 to your customer, then you'll want to do so using the detailed reassignment template (https://www.arin.net/resources/templates/reassign-detailed.txt, I think). If you have already SWIP'ed the space to them, then you'll need to submit the net-mod template (https://www.arin.net/resources/templates/netmod.txt, I think) for the /24. (Note: I'm not the person who submits SWIP templates in our organization, so I might be wrong about the particular templates to use. But the principle is still valid. It's the SWIP information filed with ARIN that determines what dns servers are authoritative for the in-addr.arpa zones for your /24's.) Ben Alternatively it is possible to delegate it using the CNAME trick used for sub-/24 allocations, which will require 256 dns records that can be made using $GENERATE. For example:- $TTL 86400 $GENERATE 0-255 $ IN CNAME $.0-255.251.250.63.in-addr.arpa. 0-255.251.250.63.in-addr.arpa. IN NS ns1.emns.com. 0-255.251.250.63.in-addr.arpa. IN NS ns2.emns.com. 0-255.251.250.63.in-addr.arpa. IN NS ns3.emns.com. 0-255.251.250.63.in-addr.arpa. IN NS ns4.emns.com. Then the customer will need to configure the zone 0-255.251.250.63.in-addr.arpa. as if it were 251.250.63.in-addr.arpa. Regards, Chris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Binding on addresses
Hi
After changing configuration from listen-on-v6 { any; }; to using
specific addresses, I observed the following in the log after issuing
`rndc reload` (times are CEST):-
29-Jul-2009 04:44:22.893 network: error: binding TCP socket: address in use
29-Jul-2009 04:44:22.893 network: error: binding TCP socket: address in use
29-Jul-2009 04:44:22.893 network: info: no longer listening on ::#53
29-Jul-2009 04:44:22.965 general: info: reloading configuration succeeded
29-Jul-2009 04:44:23.031 general: info: reloading zones succeeded
29-Jul-2009 05:19:10.179 general: info: received control channel command
'reload'
29-Jul-2009 05:19:10.180 general: info: loading configuration from
'/usr/local/bind/9.6.1-P1/etc/named.conf'
29-Jul-2009 05:19:10.182 general: info: using default UDP/IPv4 port
range: [1024, 65535]
29-Jul-2009 05:19:10.182 general: info: using default UDP/IPv6 port
range: [1024, 65535]
29-Jul-2009 05:19:10.194 general: info: reloading configuration succeeded
29-Jul-2009 05:19:10.194 general: info: reloading zones succeeded
After the reload, BIND no longer listened on tcp sockets, but udp
sockets worked ok. After restarting named, it was listening on tcp
sockets once more. Based on the log it looks like it is trying to bind
to the address-specific tcp sockets before releasing tcp [::]:53.
BIND is 9.6.1-P1 on Linux x86.
Regards,
Chris
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 hostname resolution not working
On 16/07/09 09:13, Karl Auer wrote: Windows XP cannot resolve over IPv6. It can use IPv6 addresses, but must make its DNS queries and receive its DNS responses via IPv4 transport. Sad but true. XP boxes must resolve via IPv4. As a stop-gap you can install a dns resolver (BIND, Unbound, GbDns, etc) locally and configure the dns server as 127.0.0.1. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Configuration for hostname.bind.
On 15/06/09 11:29, Andrey G. Sergeev (AKA Andris) wrote: There is no need for _any_ patch to use the built-in functionality. The patch makes queries for id.server. ch txt report the value set by the version option /by default/ without any additional configuration. Regards, Chris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Configuration for hostname.bind.
On 13/06/09 16:23, Andrey G. Sergeev (AKA Andris) wrote:
Greetings,
Sat, 13 Jun 2009 11:08:53 +0200 Chris Hills wrote:
One can change the response to version.bind. chaos txt using the
configuration directive version. Is there an equivalent
configuration directive for hostname.bind. chaos txt?
Sure:
options {
hostname any_text;
};
Also, is it possible to configure BIND to respond on version.server.
chaos txt and id.server. chaos txt in the same manner as
version.bind. and hostname.bind. (i.e. automatically without
requiring a separate zone file)?
options {
server-id any_text;
};
Thanks for the tips!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Configuration for hostname.bind.
On 13/06/09 16:23, Andrey G. Sergeev (AKA Andris) wrote:
Also, is it possible to configure BIND to respond on version.server.
chaos txt and id.server. chaos txt in the same manner as
version.bind. and hostname.bind. (i.e. automatically without
requiring a separate zone file)?
options {
server-id any_text;
};
This worked for id.server. but not version.server. The attached patch
fixes this.
Regards,
Chris
--- bind-9.6.1/bin/named/config.c.old 2009-06-14 11:18:18.514211338 +0200
+++ bind-9.6.1/bin/named/config.c 2009-06-14 11:41:48.984072797 +0200
@@ -217,6 +217,10 @@
type master;\n\
database \_builtin id\;\n\
};\n\
+ zone \version.server\ chaos {\n\
+ type master;\n\
+ database \_builtin version\;\n\
+ };\n\
};\n\
;
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Configuration for hostname.bind.
On 13/06/09 11:08, Chris Hills wrote:
Hi
One can change the response to version.bind. chaos txt using the
configuration directive version. Is there an equivalent configuration
directive for hostname.bind. chaos txt?
Also, is it possible to configure BIND to respond on version.server.
chaos txt and id.server. chaos txt in the same manner as version.bind.
and hostname.bind. (i.e. automatically without requiring a separate zone
file)?
Regards,
Chris Hills
To satisfy my curiosity I tried to specify the zones manually, using the
following in named.conf:-
zone bind CHAOS {
type master;
file master/bind.zone;
};
zone server CHAOS {
type master;
file master/server.zone;
};
However, named-checkconf said:-
/etc/named.conf:160: zone 'bind': class 'CHAOS' does not match
view/default class
/etc/named.conf:165: zone 'server': class 'CHAOS' does not match
view/default class
I could not find any reference to this message. As far as I can tell
from the documentation, this should work! I am running 9.6.1 if that helps.
Regards,
Chris
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Pruning the reverse zone tree
Chris Thompson wrote: I would welcome feedback on http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones which describes a scheme we are experimenting with for reverse lookup. (Executive summary: take RFC 2317 and carry the ideas to their [possibly] logical conclusion.) It's not BIND-specific, so I'll leave it at that for the moment. I use DNAMES to do this with zones in ip6.arpa. Personally I would like to see the upstream support it directly as it would make delegation a lot simpler. I am glad I am not the only one who likes this idea. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal
Perhaps one day MX records can be deprecated entirely in favor of SRV. Jabber got it right, and it would solve the e-mail server autodiscovery problem for clients in a generic non-proprietary manner. For example:- _smtp-server._tcp for servers, _smtp-client._tcp for clients. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
