BIND 9.4-ESVb1 is now available.

[Mark Andrews]

BIND 9.4-ESVb1 is now available.

BIND 9.4-ESVb1 is a extended release version beta for BIND 9.4.

BIND 9.4-ESVb1 can be downloaded from

ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/bind-9.4-ESVb1.tar.gz

The PGP signature of the distribution is at

ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/bind-9.4-ESVb1.tar.gz.asc
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/bind-9.4-ESVb1.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/bind-9.4-ESVb1.tar.gz.sha512.asc

The signature was generated with the ISC public key, which is
available at .

A binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.zip
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.debug.zip

The PGP signature of the binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.zip.asc
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.zip.sha512.asc
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.debug.zip.asc
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.debug.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.4-ESVb1/BIND9.4-ESVb1.debug.zip.sha512.asc

Changes since 9.4.0.

--- 9.4-ESVb1 released ---

2698.   [cleanup]   configure --enable-libbind is deprecated. [RT #20090]

2697.   [port]  win32: ensure that S_IFMT, S_IFDIR, S_IFCHR and
S_IFREG are defined after including .
[RT #20309]

2690.   [bug]   win32: fix isc_thread_key_getspecific() prototype.
[RT #20315]

2689.   [bug]   Correctly handle snprintf result. [RT #20306]

2688.   [bug]   Use INTERFACE_F_POINTTOPOINT, not IFF_POINTOPOINT,
to decide to fetch the destination address. [RT #20305]

2681.   [bug]   IPSECKEY RR of gateway type 3 was not correctly
decoded. [RT #20269]

2672.   [bug]   Don't enable searching in 'host' when doing reverse
lookups. [RT #20218]

2525.   [experimental]  New logging category "query-errors" to provide detailed
internal information about query failures, especially
about server failures.  (backported as a special
exception to the general policy) [RT #19027]

2670.   [bug]   Unexpected connect failures failed to log enough
information to be useful. [RT #20205]

2649.   [bug]   Set the domain for forward only zones. [RT #19944]

2648.   [port]  win32: isc_time_seconds() was broken. [RT #19900]

2646.   [bug]   Incorrect cleanup on error in socket.c. [RT #19987]

2642.   [bug]   nsupdate could dump core on solaris when reading
improperly formatted key files.  [RT #20015]

2640.   [security]  A specially crafted update packet will cause named
to exit. [RT #2]

2637.   [func]  Rationalize dnssec-signzone's signwithkey() calling.
[RT #19959]

2635.   [bug]   isc_inet_ntop() incorrectly handled 0.0/16 addresses.
[RT #19716]

2633.   [bug]   Handle 15 bit rand() functions. [RT #19783]

2632.   [func]  util/kit.sh: warn if documentation appears to be out of
date.  [RT #19922]

2623.   [bug]   Named started seaches for DS non-optimally. [RT #19915]

2621.   [doc]   Made copyright boilterplate consistent.  [RT #19833]

2920.   [bug]   Delay thawing the zone until the reload of it has
completed successfully.  [RT #19750]

2618.   [bug]   The sdb and sdlz db_interator_seek() methods could
loop infinitely. [RT #19847]

2617.   [bug]   ifconfig.sh failed to emit an error message when
run from the wrong location. [RT #19375]

2616.   [bug]   'host' used the nameservers from resolv.conf even
when a explicit nameserver was specified. [RT #19852]

2615.   [bug]   "__attribute__((unused))" was in the wrong place
for ia64 gcc builds. [RT #19854]

2614.   [port]  win32: 'named -v' should automatically be executed
in the foreground. [RT #19844]

2610.   [port]  sunos: Change #2363 was not complete. [RT #19796]

2606.   [bug]   "delegation-only" was not being accepted in
delegation-only type zones. [RT #19717]

2605.   [bug]   Accept DS responses from delegation only zones.
[RT # 19296]

2603.   [port]  win32: handle .exe extension of named-checkzone and
named-c

Re: Using same authoritative NSes multiple times in delegation

[Andrey G. Sergeev (AKA Andris)]

Greetings Kevin,


Wed, 18 Nov 2009 18:16:37 -0500 Kevin Darcy wrote:


Andrey G. Sergeev (AKA Andris) wrote:

Greetings,


does the following setup violate any DNS RFCs or is it in the conflict 
with any best practices?


--
[and...@strigidae ~]$ dig +nocmd +nocom +noque +nosta domain1.tld1. ns
domain1.tld1. 86400 IN NS ns1.domain1.tld1.
domain1.tld1. 86400 IN NS ns2.domain1.tld1.
domain1.tld1. 86400 IN NS ns1.domain2.tld2.
domain1.tld1. 86400 IN NS ns2.domain2.tld2.
domain1.tld1. 86400 IN NS ns1.domain3.tld3.
domain1.tld1. 86400 IN NS ns2.domain3.tld3.
ns1.domain1.tld1. 86400 IN A IP.Add.ress.1
ns2.domain1.tld1. 86400 IN A IP.Add.ress.2
^
ns1.domain2.tld2. 86400 IN A IP.Add.ress.3
^
ns2.domain2.tld2. 86400 IN A IP.Add.ress.4
ns1.domain3.tld3. 86400 IN A IP.Add.ress.2
^
ns2.domain3.tld3. 86400 IN A IP.Add.ress.3
^
--

As we can see above, the ns2.domain1.tld1 / ns1.domain3.tld3 are 
actually the same physical host with the IP.Add.ress.2 and the 
ns1.domain2.tld2 / ns2.domain3.tld3 are actually the same machine

with the IP.Add.ress.3.
The DNS standards only say that every zone must have at least 2 
nameservers. That doesn't appear to be violated here. The fact that
some of the nameservers have multiple names, doesn't reduce the 
availability/robustness of the delegations (which is apparently the 
whole point of the rule), the only minor negative effect is that

there is some confusion over where the PTR records should point. But
even that is pretty much irrelevant, since doing a reverse lookup of
an authoritative nameserver is not required by any standard, nor
something that is done in the normal course of operation.

What are the benefits of this setup?

4 nameservers are cheaper than 6 (??)


Hmm, may be. I suppose that this setup creates an added redundancy and
seems to be more reliable. If all of these 6 nameservers would be in the
same TLD, then simply cutting off this TLD from the DNS namespace would
be sufficient to cut off the delegated domain too:

domain1.tld1 delegated to:
  ns1.domain1.tld1
  ns2.domain1.tld1
  ns1.domain2.tld1
  ns2.domain2.tld1
  ns1.domain3.tld1
  ns2.domain3.tld1

In this scenario the tld1 is the single POF.

But if we have something like this

domain1.tld1 delegated to:
  ns1.domain1.tld1
  ns2.domain1.tld1
  ns1.domain2.tld2
  ns2.domain2.tld2
  ns1.domain3.tld3
  ns2.domain3.tld3

then we have an additional level of redundancy. The idea is that we
should distribute out authoritative nameservers not only across
different IP networks, ASes and ISPs, but also among different TLDs and
SLDs. It can be expensive to setup 6 completely different nameservers so
we can emulate the redundancy by creating the aliases for our existing
nameservers.

We're still vulnerable because if we have tld1 completely unavailable
then it would be rather difficult to determine the full list of
authoritative nameservers for any domains in tld1 - but don't forget
about the cached data.


--

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: Using same authoritative NSes multiple times in delegation

[Kevin Darcy]

Andrey G. Sergeev (AKA Andris) wrote:

Greetings,


does the following setup violate any DNS RFCs or is it in the conflict 
with any best practices?


--
[and...@strigidae ~]$ dig +nocmd +nocom +noque +nosta domain1.tld1. ns
domain1.tld1. 86400 IN NS ns1.domain1.tld1.
domain1.tld1. 86400 IN NS ns2.domain1.tld1.
domain1.tld1. 86400 IN NS ns1.domain2.tld2.
domain1.tld1. 86400 IN NS ns2.domain2.tld2.
domain1.tld1. 86400 IN NS ns1.domain3.tld3.
domain1.tld1. 86400 IN NS ns2.domain3.tld3.
ns1.domain1.tld1. 86400 IN A IP.Add.ress.1
ns2.domain1.tld1. 86400 IN A IP.Add.ress.2
^
ns1.domain2.tld2. 86400 IN A IP.Add.ress.3
^
ns2.domain2.tld2. 86400 IN A IP.Add.ress.4
ns1.domain3.tld3. 86400 IN A IP.Add.ress.2
^
ns2.domain3.tld3. 86400 IN A IP.Add.ress.3
^
--

As we can see above, the ns2.domain1.tld1 / ns1.domain3.tld3 are 
actually the same physical host with the IP.Add.ress.2 and the 
ns1.domain2.tld2 / ns2.domain3.tld3 are actually the same machine with 
the IP.Add.ress.3.
The DNS standards only say that every zone must have at least 2 
nameservers. That doesn't appear to be violated here. The fact that some 
of the nameservers have multiple names, doesn't reduce the 
availability/robustness of the delegations (which is apparently the 
whole point of the rule), the only minor negative effect is that there 
is some confusion over where the PTR records should point. But even that 
is pretty much irrelevant, since doing a reverse lookup of an 
authoritative nameserver is not required by any standard, nor something 
that is done in the normal course of operation.


What are the benefits of this setup?

4 nameservers are cheaper than 6 (??)

- Kevin

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND Secondaries of MS AD Integrated Zones

[bsfinkel]

jim.siffe...@tektronix.com wrote:

>Most of our internal DNS zones are mastered in Microsoft DNS (2k3 R2)
>as AD Integrated zones.  Currently, those zones are slaved from a
>single MS DNS server to our BIND 9 servers that handle recursion.  Is
>there a reliable way to use multiple masters when slaving AD Integrated
>zones to BIND?
>
>In the O'Reilly book "DNS on Windows Server 2003" a section on p. 324
>called "BIND Secondaries for Active Directory-Integrated Zones" says
>serial numbers can vary on otherwise synchronized MS DNS Servers,
>potentially causing a server to respond with an incorrect lower serial
>number.
>
>Thanks,
>
>Jim Sifferle
>Tektronix / Fluke Network Services

I have seen the replies to this mail, and I have something else to add.
See MS 282826.  Assume that you have a zone that is AD-integerated,
and you have the zone on two DCs, DC1 and DC2 - both are running the
MS DNS Service.  Assume that both copies of the zone are identical
and have serial number, say, 1.

Now two machines send DDNS updates for the same zone at the same time;
one sends to DC1 and one sends to DC2.  After each DC has processed
the update, the DCs now have serial number 2, but the zones have
different content.  Somehow (under the covers of AD), the two zones are
synchronized.  I do not know the algorithm, nor do I know how much time
elapses before the synchronization.  With the synchronized zone, what
is the proper serial number?  It can not be 2, as there could be
another DDNS packet for the same zone sent to DC1, and this results
(before the synchronization) to DC1 having serial number 2 and DC2
having serial number 1.  Article 282826 describes what the MS code does;
it depends upon what MS DNS Servers are treated as masters for BIND.

With my setup, I run only ONE MS DNS Server, even though I have four
DCs.  My Windows group wants two MS DNS Servers, and I will list only]
one as the master for the zone on my BIND servers.
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory  Phone:+1 (630) 252-7277
9700 South Cass Avenue   Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL   60439-4828 IBMMAIL:  I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Using same authoritative NSes multiple times in delegation

[Andrey G. Sergeev (AKA Andris)]

Greetings,


does the following setup violate any DNS RFCs or is it in the conflict 
with any best practices?


--
[and...@strigidae ~]$ dig +nocmd +nocom +noque +nosta domain1.tld1. ns
domain1.tld1.   86400   IN  NS  ns1.domain1.tld1.
domain1.tld1.   86400   IN  NS  ns2.domain1.tld1.
domain1.tld1.   86400   IN  NS  ns1.domain2.tld2.
domain1.tld1.   86400   IN  NS  ns2.domain2.tld2.
domain1.tld1.   86400   IN  NS  ns1.domain3.tld3.
domain1.tld1.   86400   IN  NS  ns2.domain3.tld3.
ns1.domain1.tld1.   86400   IN  A   IP.Add.ress.1
ns2.domain1.tld1.   86400   IN  A   IP.Add.ress.2
^
ns1.domain2.tld2.   86400   IN  A   IP.Add.ress.3
^
ns2.domain2.tld2.   86400   IN  A   IP.Add.ress.4
ns1.domain3.tld3.   86400   IN  A   IP.Add.ress.2
^
ns2.domain3.tld3.   86400   IN  A   IP.Add.ress.3
^
--

As we can see above, the ns2.domain1.tld1 / ns1.domain3.tld3 are 
actually the same physical host with the IP.Add.ress.2 and the 
ns1.domain2.tld2 / ns2.domain3.tld3 are actually the same machine with 
the IP.Add.ress.3.


What are the benefits of this setup?

Thanks in advance.


--

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: BIND does not listen at all when the interface is temporarily down (only with IPv6)

[Chris Buxton]

On Nov 18, 2009, at 8:36 AM, Stephane Bortzmeyer wrote:

> When I listen on one specific address:
> 
> listen-on-v6 { 2001:db8::53;}; 
> 
> If the interface is not UP at the time BIND starts, and therefore this
> IP address not local, BIND does not listen:
> 
> 18-Nov-2009 17:31:24.588 not listening on any interfaces
> 
> and does not resume if the interface becomes UP later. (I have to rndc
> reload.) Very annoying.
> 
> This does not occur with IPv4 and the listen-on directive.

Yes it does. If you put named built from stock source on Mac OS X, enable the 
stock Apple launchd job for named, and restart, named will be deaf because the 
ethernet interface is not up by the time named starts. You have to reload it, 
or wait for the statistics interval, for it to come up on the Ethernet 
interface. (It will be listening on the loopback interface right away, though.)

If you use the "any" token in your listen-on-v6 list, instead of specific 
interfaces, it will listen on the wildcard interface. This way, it will start 
listening right away when the interface comes up. This is different than for 
the IPv4 stack.

Chris Buxton
Professional Services
Men & Mice

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind sometimes SERVFAIL

[Kevin Darcy]

Luis Daniel Lucio Quiroz wrote:

Le mercredi 11 novembre 2009 09:15:12, Matus UHLAR - fantomas a écrit :
  

On 11.11.09 16:05, Pawel Rutkowski wrote:


Please look below, it's normal ? Sometime servfail, sometimes nxdomain.

[r...@linux ~]# host 209.85.255.187 ns1.isp
Using domain server:
Name: ns1.isp
Address: ns1.isp#53
Aliases:

Host 187.255.85.209.in-addr.arpa not found: 2(SERVFAIL)
[r...@linux ~]# host 209.85.255.187 ns1.isp
Using domain server:
Name: ns1.isp
Address: ns1.isp#53
Aliases:

Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN)
[r...@linux ~]# host 209.85.255.187 ns1.isp
Using domain server:
Name: ns1.isp
Address: ns1.isp#53
Aliases:

Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN)
  

Use 'dig -x 209.85.255.187 @ns1.isp' and look at "NS" records and TTLs.
Invalid delegations and inconsistent NS records (domain is delegated from
parent to different servers than those listed in the domain) often cause
these kinds of problems.



I think I did have same problem
with 9.4.1p1, 9.5p2 and 9.6p1. Look

[d...@brandmauer ~]$ host www.bbc.co.uk 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

www.bbc.co.uk is an alias for www.bbc.net.uk.
www.bbc.net.uk has address 212.58.253.68
Host www.bbc.net.uk not found: 2(SERVFAIL)
[d...@brandmauer ~]$

  

By default, "host" looks up A,  and MX records, in that order.
I did sniff connecction and It seems that the query that fails is a MX request 
of www.bbc.net.mx. Odd thing.


  
The delegated nameservers for bbc.net.uk are answering an MX query with 
an A record:


$ dig www.bbc.net.uk mx @ns0.rbsov.bbc.co.uk +short
212.58.253.68
$ dig www.bbc.net.uk mx @ns0.thdo.bbc.co.uk +short 
212.58.253.68


Really bad stuff, but this is a *persistent* condition, caused by the 
domain owner(s), and probably not related to the issue reported by the 
previous poster.


  - Kevin







___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind sometimes SERVFAIL

[Luis Daniel Lucio Quiroz]

Le mercredi 11 novembre 2009 09:15:12, Matus UHLAR - fantomas a écrit :
> On 11.11.09 16:05, Pawel Rutkowski wrote:
> > Please look below, it's normal ? Sometime servfail, sometimes nxdomain.
> >
> > [r...@linux ~]# host 209.85.255.187 ns1.isp
> > Using domain server:
> > Name: ns1.isp
> > Address: ns1.isp#53
> > Aliases:
> >
> > Host 187.255.85.209.in-addr.arpa not found: 2(SERVFAIL)
> > [r...@linux ~]# host 209.85.255.187 ns1.isp
> > Using domain server:
> > Name: ns1.isp
> > Address: ns1.isp#53
> > Aliases:
> >
> > Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN)
> > [r...@linux ~]# host 209.85.255.187 ns1.isp
> > Using domain server:
> > Name: ns1.isp
> > Address: ns1.isp#53
> > Aliases:
> >
> > Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN)
> 
> Use 'dig -x 209.85.255.187 @ns1.isp' and look at "NS" records and TTLs.
> Invalid delegations and inconsistent NS records (domain is delegated from
> parent to different servers than those listed in the domain) often cause
> these kinds of problems.
> 
I think I did have same problem
with 9.4.1p1, 9.5p2 and 9.6p1. Look

[d...@brandmauer ~]$ host www.bbc.co.uk 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

www.bbc.co.uk is an alias for www.bbc.net.uk.
www.bbc.net.uk has address 212.58.253.68
Host www.bbc.net.uk not found: 2(SERVFAIL)
[d...@brandmauer ~]$


I did sniff connecction and It seems that the query that fails is a MX request 
of www.bbc.net.mx. Odd thing.

When I ask to a exchange dns server, query is okay.

Is this a bug?

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND does not listen at all when the interface is temporarily down (only with IPv6)

[Stephane Bortzmeyer]

When I listen on one specific address:

listen-on-v6 { 2001:db8::53;}; 

If the interface is not UP at the time BIND starts, and therefore this
IP address not local, BIND does not listen:

18-Nov-2009 17:31:24.588 not listening on any interfaces

and does not resume if the interface becomes UP later. (I have to rndc
reload.) Very annoying.

This does not occur with IPv4 and the listen-on directive.

Tested with BIND 9.5.1 and 9.7b2 on Debian/Linux.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS records visible only for LAN computers

[Kevin Darcy]

Peter Macko wrote:

Setup:
I have a domain example.com that is hosted on DNS under control of my 
internet provider.

Web server www.example.com is hosted by another company.
I have setup a local DNS for computers on my LAN. I have a LDAP server 
on LAN.


Question:
I want to make LDAP visible only for computers on LAN without altering 
DNS (of the internet provider).
The name of LDAP server should be ldap.example.com. Is it possible to 
do it?


I can think of two solutions:
1) I could create master zone for example.com on DNS (on LAN). This 
way I have to create A record for www.example.com,
but if internet provider changed ip address of the web-server, 
computers on lan would not reach

www.example.com and I would have to update A record on local DNS.

2) Another solution is to create zonefile for subdomain 
local.example.com on LAN DNS, so ldap.local.example.com.

But this is not exactly what I want.

3) Create a zone called "ldap.example.com". Put the A record for your 
LDAP server at the apex of the zone.


Obviously, this isn't really scalable -- you don't want to have to 
create zones and zone definitions for every resource on your LAN, but 
this is the price you pay for being so disjointed from your 
webservice/external-DNS provider that they don't even bother telling you 
when they change the IPs of your main website. If you want scalability, 
you should take control of example.com yourself and then implement 
something like "view"s to control how it is presented to internal versus 
external clients.



  - Kevin


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Non English Domain names

[Stephane Bortzmeyer]

On Wed, Nov 18, 2009 at 04:14:14PM +0200,
 Sener ATAS  wrote 
 a message of 106 lines which said:

> www.xn--b-eha.edu.tr

But you could fix a few name servers:

% check_soa xn--b-eha.edu.tr
asiyan.cc.boun.edu.tr has serial number 1219834947
There was no response from simurg.cc.boun.edu.tr
There was no response from ardic.cc.boun.edu.tr
foca.cc.boun.edu.tr has serial number 1219834947
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Non English Domain names

[Jukka Pakkanen]

Yeah, no problems with scandinavian letters either.

http://en.wikipedia.org/wiki/Punycode


Sener ATAS kirjoitti:

Hi,

We use bind with turkish characters. And it works perfectly.
for *www.bü.edu.tr* you must edit your zone like *www.xn--b-eha.edu.tr

*Alans wrote:


Hi,

 

I know this is a little bit off topic but I would like to know how 
BIND will handle non English domain names? How this effect Bind?


ICANN started working on non English domains from today as far as I know.

 

 


Regards,

Alans



___
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


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Non English Domain names

[Stephane Bortzmeyer]

On Wed, Nov 18, 2009 at 03:36:56PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 25 lines which said:

> If you are talking about IDN (Internationalized Domain Names), domain
> names in Unicode, the way they are specified, they don't require a
> change in the name servers, so BIND can handle them just fine.

BTW, the Wikipedia article seems quite comprehensive:

http://en.wikipedia.org/wiki/Internationalized_domain_name

And, to translate names from Unicode to the ASCII encoding used in
zone files, you can use various command-line tools or a Web one:

http://josefsson.org/idn.php/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Non English Domain names

[Stephane Bortzmeyer]

On Wed, Nov 18, 2009 at 04:38:22PM +0300,
 Alans  wrote 
 a message of 141 lines which said:

> I know this is a little bit off topic but I would like to know how
> BIND will handle non English domain names?

Non-English domain names? What's that? Is coca-cola.com an english
domain name? I do not find Coca-Cola in the Webster. And is
jeanne-d-arc.fr an english domain name?

If you are talking about IDN (Internationalized Domain Names), domain
names in Unicode, the way they are specified, they don't require a
change in the name servers, so BIND can handle them just fine.
 
> ICANN started working on non English domains from today as far as I
> know.

ICANN, may be, but the rest of the world is working with IDN for at
least six years (the standard was issued in 2003 and the first
implementations appeared immediately).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Non English Domain names

[Sener ATAS]

Hi,

We use bind with turkish characters. And it works perfectly.
for www.bü.edu.tr you must edit your zone like www.xn--b-eha.edu.tr

Alans wrote:

  
  
  

  
  Hi,
   
  I know this is a little bit off topic but I
would like to
know how BIND will handle non English domain names? How this effect
Bind?
  ICANN started working on non English domains
from today as
far as I know.
   
   
  Regards,
  Alans
  
  

___
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

Non English Domain names

[Alans]

Hi,

 

I know this is a little bit off topic but I would like to know how BIND will
handle non English domain names? How this effect Bind?

ICANN started working on non English domains from today as far as I know.

 

 

Regards,

Alans

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users