UNSUBSCRIBE

Fernando Nerio Fernandez fernando.nerio at corp.terralycos.com
Mon Oct 13 13:47:14 UTC 2003


UNSUBSCRIBE

-----Original Message-----
From: BIND Users Mailing List [mailto:bind-users at isc.org]
Sent: Saturday, October 11, 2003 2:50 AM
To: bind-users digest users
Subject: bind-users Digest V5 #274


bind-users Digest	Fri, 10 Oct 2003	Volume: 05  Issue: 274

In This Issue:
		URL Forwarding
		Re: URL Forwarding 
		Re: Resolver Error 0 (no error)
		delegation-only can break .name
		RE: delegation-only can break .name
		Re: URL Forwarding
		2 nic, dynamic ip best practice ?
		dns web utilities
		RE: delegation-only can break .name
		Re: delegation-only can break .name
		SERVFAIL response for dig but +trace works
		issues with mcd.com DNS
		DNS Query Format
		Re: SERVFAIL response for dig but +trace works 
		Re: DNS Query Format 
		Re: delegation-only can break .name

----------------------------------------------------------------------

Date: Sat, 11 Oct 2003 06:12:38 -0600 (CST)
Subject: URL Forwarding
From: <chris at rockfort.com>

I have 2 domain names, siteA.com  and siteB.com
I would to forward siteB.com to SiteA.com so that whenever siteB.com is
requested, it automatically ends up at siteA.
in the zone record for siteB.com I propose to do the following, please tell
me if this is the correct way to accomplish this:


$ORIGIN siteB.com
$TTL 86400
@     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day

      IN     NS     dns1.domain.com.
      IN     NS     dns2.domain.com.


www          IN     CNAME   siteA.com

WOULD there need to be any other directive to add to the above zone file to
accomplish this goal? ot is this altogether incorrect. If so what is the
proper way to do this. Again all I want ot do is to forward www.siteB.com
to www.siteA.com

Thanks

Chris








------------------------------

Subject: Re: URL Forwarding 
From: "Owen McShane" <omcshane at vianetworks.co.uk>
Date: Fri, 10 Oct 2003 14:25:49 +0100

> I have 2 domain names, siteA.com  and siteB.com
> I would to forward siteB.com to SiteA.com so that whenever siteB.com is
> requested, it automatically ends up at siteA.
> in the zone record for siteB.com I propose to do the following, please
tell
> me if this is the correct way to accomplish this:
> 
> 
> $ORIGIN siteB.com
> $TTL 86400
> @     IN     SOA    dns1.domain.com.     hostmaster.domain.com. (
>                     2001062501 ; serial
>                     21600      ; refresh after 6 hours
>                     3600       ; retry after 1 hour
>                     604800     ; expire after 1 week
>                     86400 )    ; minimum TTL of 1 day
> 
>       IN     NS     dns1.domain.com.
>       IN     NS     dns2.domain.com.
> 
> 
> www          IN     CNAME   siteA.com
> 
> WOULD there need to be any other directive to add to the above zone file
to
> accomplish this goal? ot is this altogether incorrect. If so what is the
> proper way to do this. Again all I want ot do is to forward www.siteB.com
> to www.siteA.com

www		IN	CNAME	www.siteA.com.

would give www.siteA.com the same IP as www.siteA.com (note the trailing .
is essential, otherwise it would equate to www.siteA.com.siteB.com)

Bear in mind that the web server will need to be accepting requests for that
host header also.

Owen

------------------------------

From: Barry Margolin <barry.margolin at level3.com>
Subject: Re: Resolver Error 0 (no error)
Date: Fri, 10 Oct 2003 14:10:25 GMT

In article <bm4npi$1ahm$1 at sf1.isc.org>,
Bobby Johnson  <Bobby.Johnson at esecurityinc.com> wrote:
>I wish that were my problem, but I get the same error with other servers as
>well...
>> nslookup www.dell.com ns-east.cerf.net
>*** Can't find server address for 'ns-east.cerf.net': Resolver Error 0 (no
>error)
>
>Server:  ns.mydomain.com
>Address:  10.10.10.12
>
>Non-authoritative answer:
>Name:    www.ins.dell.com
>Address:  143.166.224.230
>Aliases:  www.dell.com
>
>
>I just noticed the error that dig displays....
>> dig @ns-east.cerf.net www.dell.com
>
>; <<>> DiG 8.3 <<>> @ns-east.cerf.net www.dell.com
>; Bad server: ns-east.cerf.net -- using default server and timer opts
>; (1 server found)
>[snip]

Check you /etc/nsswitch.conf -- maybe you're configured to use another
resolving mechanism, and it's failing.

-- 
Barry Margolin, barry.margolin at level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the
group.

------------------------------

Subject: delegation-only can break .name
From: Aage Strand <astrand at gnr.com>
Date: Fri, 10 Oct 2003 15:32:16 +0100

Dear ISC,

Recently, in response to the introduction of wildcard records for .com and
.net, the ISC added functionality to BIND that modifies some answers given
by name servers to NXDOMAIN responses. It turns out that certain ISPs and
other DNS server operators have not deployed this patch on a
necessity-only basis. As a result, certain services supplied by operators
of TLD servers are experiencing operational issues.

The .name gTLD works by allowing a user to register the address
firstname at lastname.name. Currently, MX records for lastname.name are
issued by the authoritative .name servers. This is part of the original
agreement between the .name operator and ICANN, and can be read here:

http://www.icann.org/tlds/agreements/name/registry-agmt-appc-1-8aug03.htm#d

Anyone who configures the .name zone as delegation-only, or fails to
exclude .name from their root-delegation-only configuration, is currently
blocking email to any address of the type firstname at lastname.name. This
includes ALL people who have registered their .name email-forwarding
address.

We recommend that the root-delegation-only functionality be removed from
future versions of BIND, and that delegation-only functionality be
deployed by DNS operators on a strict necessity-only basis. We suggest
that users be given a clear warning of the possible consequences of using
this configuration, possibly with warnings in the logs and/or warnings on
start-up of BIND.

We kindly ask that the ISC take reasonable measures to inform BIND
operators of the need to exclude the .name gTLD from any delegation only
functionality. Any additional steps that can be taken to inform operators
that have downloaded this specific patch would be much appreciated.

This sample query against the ISC resolving name server clearly
demonstrates the consequences for .NAME customers if ISPs deploy the
delegation-only functionality without excluding the .NAME zone:

$ dig @204.152.184.76 smith.name mx

; <<>> DiG 9.2.1 <<>> @204.152.184.76 smith.name mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63359
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;smith.name.			IN	MX

;; Query time: 2699 msec
;; SERVER: 204.152.184.76#53(204.152.184.76)
;; WHEN: Fri Oct 10 15:29:30 2003
;; MSG SIZE  rcvd: 28



Best Regards,
Aage Strand


-- 
Aage Strand
Development Manager
Global Name Registry Ltd.

Information contained herein is Global Name Registry Proprietary
Information and is made available to you because of your interest in our
company. This information is submitted in confidence and its disclosure 
to you is not intended to constitute public disclosure or authorization 
for disclosure to other parties.



------------------------------

Subject: RE: delegation-only can break .name
Date: Fri, 10 Oct 2003 08:13:00 -0700
From: <Jeremy_Powell at sbcss.k12.ca.us>

Isn't this what the excludes part of the
root-delegation-only is meant for.  However,
I have wondered since the introduction of
root-delegation-only why it did not default
to none with an include list rather than
default to all with an exclude list?

Jeremy Powell

> -----Original Message-----
> From: Aage Strand [mailto:astrand at gnr.com]
> Sent: Friday, October 10, 2003 7:32 AM
> To: bind-suggest at isc.org
> Cc: bind-users at isc.org; bind9-users at isc.org
> Subject: delegation-only can break .name
>=20
>=20
> Dear ISC,
>=20
> Recently, in response to the introduction of wildcard records=20
> for .com and
> .net, the ISC added functionality to BIND that modifies some=20
> answers given
> by name servers to NXDOMAIN responses. It turns out that=20
> certain ISPs and
> other DNS server operators have not deployed this patch on a
> necessity-only basis. As a result, certain services supplied=20
> by operators
> of TLD servers are experiencing operational issues.
>=20
> The .name gTLD works by allowing a user to register the address
> firstname at lastname.name. Currently, MX records for lastname.name are
> issued by the authoritative .name servers. This is part of=20
> the original
> agreement between the .name operator and ICANN, and can be read here:
>=20
> http://www.icann.org/tlds/agreements/name/registry-agmt-appc-1
> -8aug03.htm#d
>=20
> Anyone who configures the .name zone as delegation-only, or fails to
> exclude .name from their root-delegation-only configuration,=20
> is currently
> blocking email to any address of the type=20
> firstname at lastname.name. This
> includes ALL people who have registered their .name email-forwarding
> address.
>=20
> We recommend that the root-delegation-only functionality be=20
> removed from
> future versions of BIND, and that delegation-only functionality be
> deployed by DNS operators on a strict necessity-only basis. We suggest
> that users be given a clear warning of the possible=20
> consequences of using
> this configuration, possibly with warnings in the logs and/or=20
> warnings on
> start-up of BIND.
>=20
> We kindly ask that the ISC take reasonable measures to inform BIND
> operators of the need to exclude the .name gTLD from any=20
> delegation only
> functionality. Any additional steps that can be taken to=20
> inform operators
> that have downloaded this specific patch would be much appreciated.
>=20
> This sample query against the ISC resolving name server clearly
> demonstrates the consequences for .NAME customers if ISPs deploy the
> delegation-only functionality without excluding the .NAME zone:
>=20
> $ dig @204.152.184.76 smith.name mx
>=20
> ; <<>> DiG 9.2.1 <<>> @204.152.184.76 smith.name mx
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63359
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>=20
> ;; QUESTION SECTION:
> ;smith.name.			IN	MX
>=20
> ;; Query time: 2699 msec
> ;; SERVER: 204.152.184.76#53(204.152.184.76)
> ;; WHEN: Fri Oct 10 15:29:30 2003
> ;; MSG SIZE  rcvd: 28
>=20
>=20
>=20
> Best Regards,
> Aage Strand
>=20
>=20
> --=20
> Aage Strand
> Development Manager
> Global Name Registry Ltd.
>=20
> Information contained herein is Global Name Registry Proprietary
> Information and is made available to you because of your=20
> interest in our
> company. This information is submitted in confidence and its=20
> disclosure=20
> to you is not intended to constitute public disclosure or=20
> authorization=20
> for disclosure to other parties.
>=20
>=20
>=20
>=20


_________________________________________________________________________=
________

Statement of Confidentiality:  The contents of this e-mail message and =
any attachments are intended solely for the addressee.  The information =
may also be confidential and/or legally privileged.  This transmission =
is sent for the sole purpose of delivery to the intended recipient.  If =
you have received this transmission in error, any use, reproduction, or =
dissemination of this transmission is strictly prohibited.  If you are =
not the intended recipient, please immediately notify the sender by =
reply e-mail, send a copy to postmaster at sbcss.k12.ca.us and delete this =
message and its attachments, if any.

E-mail is covered by the Electronic Communications Privacy Act, 18 USC =
SS 2510-2521 and is legally privileged. =20

Date Sent (d/m/yy): 10/10/2003  -  Sender: Jeremy_Powell at sbcss.k12.ca.us


------------------------------

From: Walter Schiessberg <w.schiessberg at members.uceprotect.net>
Subject: Re: URL Forwarding
Date: Fri, 10 Oct 2003 14:56:00 +0200

chris at rockfort.com wrote on 11.10.2003 14:12:


[...]
> www          IN     CNAME   siteA.com
> 
> WOULD there need to be any other directive to add to the above zone file
to
> accomplish this goal? ot is this altogether incorrect. If so what is the
> proper way to do this. Again all I want ot do is to forward www.siteB.com
> to www.siteA.com

Try
www          IN     CNAME   www.siteA.com.
                             ^^^          ^

Walter


------------------------------

From: linuxjaver at yahoo.com (dns-slacker)
Subject: 2 nic, dynamic ip best practice ?
Date:  10 Oct 2003 03:58:06 -0700

Hi ppl,

Wut is the best design concept for 2 nic, dynamic ip ?
Am thinking to configure eth0 for resolving private IPs,
eth2 for zone mydomain.com.

Is it ok to run own primary dnsserver, while have the 2nd server
hosted by a ddns/public dns-server (I registered 1 by granite canyon).
Or should I have them both hosted by ddns/public dns server ?

In this case, how can I tell the 2nd dns server about my IP each time?

Can any one post an example of :
/etc/{hosts,resolv.conf}, named.conf, mydomain.zone ?

Am thanking in advands for possible helps ..

------------------------------

From: dave <dave_member at newsguy.com>
Subject: dns web utilities
Date: 9 Oct 2003 21:27:21 -0700

hi:

can anyone here recommend web based utility tools (free or commerical) for
management of dns master files? basically i don't want the dns admin to have
the
root access but only use web interface to manage dns files.

thanks

dave


------------------------------

Date: Fri, 10 Oct 2003 20:05:30 +0200 (CEST)
From: Ketil Froyn <isc_bind at ketil.froyn.name>
Subject: RE: delegation-only can break .name

On Fri, 10 Oct 2003 Jeremy_Powell at sbcss.k12.ca.us wrote:

> Isn't this what the excludes part of the root-delegation-only is meant
> for.  However, I have wondered since the introduction of
> root-delegation-only why it did not default to none with an include list
> rather than default to all with an exclude list?

Because that's what the delegation-only feature does.

Anyway, even ISC themselves haven't added the "name" zone to their exclude
list, as shown on their web page and by the example given:

  dig @204.152.184.76 smith.name mx

(which should not return NXDOMAIN) so it is unlikely that many others
using this new functionality has. As an example, anyone using the example
given on the ISC website for root-delegation-only will bounce mail to
ketil at froyn.name.

Also, anyone forwarding .name queries to ISC's DNS servers will bounce
mail to ketil at froyn.name.

Finally, anyone who has classified the .name zone as delegation-only has
probably done so because they got caught up in the tide of the times
rather than because they really needed to, for whatever reason, and it
will cause mail to ketil at froyn.name to bounce.

Ketil Froyn
ketil at froyn.name
http://ketil.froyn.name/


------------------------------

From: Peter Losher <Peter_Losher at isc.org>
Subject: Re: delegation-only can break .name
Date: Fri, 10 Oct 2003 04:48:45 -0700

On Friday 10 October 2003 11:05 am, Ketil Froyn wrote:

> Anyway, even ISC themselves haven't added the "name" zone to their
> exclude list, as shown on their web page and by the example given:

That has been changed as of an hour ago; see:

http://www.isc.org/products/BIND/delegation-only.html

Best Wishes - Peter
-- 
Peter_Losher at isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow"


------------------------------

Date: Fri, 10 Oct 2003 17:13:29 -0400
From: Ken Hays <hays at acns.fsu.edu>
Subject: SERVFAIL response for dig but +trace works

Hi folks,  I am in an unfortunate hurry. 


I have not found the FAQ for this list yet. Is there one?

I have found the archives and not yet found what I need. 

The server in question is the "main" server for the FSU.EDU. 
The good news is that it has only 197 zones. It is running  
BIND 9.2.2-P3 on a SUN, details follows: uname -a
SunOS dns1 5.8 Generic_108528-20 sun4u sparc SUNW,Sun-Fire-280R

fwiw - We have *NOT* activated the "delegation" only options in 
the named.conf.

I am seeing a number of domains getting either "SERVFAIL" or
";; connection timed out; no servers could be reached" in 
response to dig.  Suggestions for what "logging" or "debugging"
options to turn on are invited. I would like to get some 
handle on "For ow much of the DNS are we getting bad answers?"

I would like someone to explain the following dig output to me. 
I do not see the reason the +trace works and the original did not.

pamd1:~:130$ dig @128.186.6.103 mktrading.org.

; <<>> DiG 9.2.2 <<>> @128.186.6.103 mktrading.org.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6312
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mktrading.org.                 IN      A

;; Query time: 1 msec
;; SERVER: 128.186.6.103#53(128.186.6.103)
;; WHEN: Fri Oct 10 16:44:51 2003
;; MSG SIZE  rcvd: 31

pamd1:~:131$ dig @128.186.6.103 mktrading.org. +trace

; <<>> DiG 9.2.2 <<>> @128.186.6.103 mktrading.org. +trace
;; global options:  printcmd
.                       276543  IN      NS      D.ROOT-SERVERS.NET.
.                       276543  IN      NS      E.ROOT-SERVERS.NET.
.                       276543  IN      NS      F.ROOT-SERVERS.NET.
.                       276543  IN      NS      G.ROOT-SERVERS.NET.
.                       276543  IN      NS      H.ROOT-SERVERS.NET.
.                       276543  IN      NS      I.ROOT-SERVERS.NET.
.                       276543  IN      NS      J.ROOT-SERVERS.NET.
.                       276543  IN      NS      K.ROOT-SERVERS.NET.
.                       276543  IN      NS      L.ROOT-SERVERS.NET.
.                       276543  IN      NS      M.ROOT-SERVERS.NET.
.                       276543  IN      NS      A.ROOT-SERVERS.NET.
.                       276543  IN      NS      B.ROOT-SERVERS.NET.
.                       276543  IN      NS      C.ROOT-SERVERS.NET.
;; Received 356 bytes from 128.186.6.103#53(128.186.6.103) in 2 ms

org.                    172800  IN      NS      TLD1.ULTRADNS.NET.
org.                    172800  IN      NS      TLD2.ULTRADNS.NET.
;; Received 113 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 24 ms

MKTRADING.ORG.          172800  IN      NS      NS1.MOOSENET.COM.
MKTRADING.ORG.          172800  IN      NS      NS2.MOOSENET.COM.
;; Received 92 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 33 ms

mktrading.org.          43200   IN      A       216.98.140.253
mktrading.org.          43200   IN      NS      ns2.aspadmin.com.
mktrading.org.          43200   IN      NS      ns3.aspadmin.com.
mktrading.org.          43200   IN      NS      ns1.aspadmin.com.
;; Received 161 bytes from 216.98.155.52#53(NS1.MOOSENET.COM) in 89 ms

Thanks for getting all the way through the message, Ken
-- 
 ---------------------------------------------------------------------
 Kenneth M. Hays                                hays at acns.fsu.edu 
 Academic Computing and Network Services        aka kmh8 at the NIC
 Florida State University                       voice=850-644-2591x129
 2035 East Paul Dirac Drive                     fax=850-644-8722
 Tallahassee, Florida 32306-2760                eFax=773-913-0894
 ---------------------------------------------------------------------

------------------------------

From: Dave Lugo <dlugo at etherboy.com>
Subject: issues with mcd.com DNS
Date: Fri, 10 Oct 2003 16:53:53 -0400

Hello,

Running 9.2.3rc4 (previously running 9.2.2 with the same problem), on linux.


The problem I'm occasionally seeing is this:

On my DNS server, I can query for mcd.com's MX, with no problem.

On other boxes in the same subnet as my DNS server, that same query 
against my DNS server fail.


This doesn't happen often, but when it does it's a PITA.  To fix it,
I have to restart my named. Any suggestions for stuff I should look at 
would be appreciated.

As for mcd.com's somewhat broken DNS configuration, it's not something I 
am able to resolve myself, but I have pointed it out to them.  I'm not 
sure that their b0rkeness is what is causing my problem

Thanks very much,

Dave

-- 
--------------------------------------------------------
Dave Lugo   dlugo at etherboy.com    LC Unit #260   TINLC
Have you hugged your firewall today?   No spam, thanks.
--------------------------------------------------------
Are you the police?  . . . .  No ma'am, we're sysadmins.


------------------------------

From: "Keith Alexander" <Keith2003 at yahoo.com>
Subject: DNS Query Format
Date: Fri, 10 Oct 2003 21:37:36 GMT

I need the DNS Query and response format at binary level. When a client
sends a request to a DNS server to resolve a name like yahoo.com, what
exactly is the format of the data sent using UDP port 53? Also, what is the
format of response sent by the server back to the client?

Keith


------------------------------

From: Mark_Andrews at isc.org
Subject: Re: SERVFAIL response for dig but +trace works 
Date: Sat, 11 Oct 2003 10:34:06 +1000


> Hi folks,  I am in an unfortunate hurry. 
> 
> 
> I have not found the FAQ for this list yet. Is there one?
> 
> I have found the archives and not yet found what I need. 
> 
> The server in question is the "main" server for the FSU.EDU. 
> The good news is that it has only 197 zones. It is running  
> BIND 9.2.2-P3 on a SUN, details follows: uname -a
> SunOS dns1 5.8 Generic_108528-20 sun4u sparc SUNW,Sun-Fire-280R
> 
> fwiw - We have *NOT* activated the "delegation" only options in 
> the named.conf.
> 
> I am seeing a number of domains getting either "SERVFAIL" or
> ";; connection timed out; no servers could be reached" in 
> response to dig.  Suggestions for what "logging" or "debugging"
> options to turn on are invited. I would like to get some 
> handle on "For ow much of the DNS are we getting bad answers?"
> 
> I would like someone to explain the following dig output to me. 
> I do not see the reason the +trace works and the original did not.
> 
> pamd1:~:130$ dig @128.186.6.103 mktrading.org.
> 
> ; <<>> DiG 9.2.2 <<>> @128.186.6.103 mktrading.org.
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6312
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;mktrading.org.                 IN      A
> 
> ;; Query time: 1 msec
> ;; SERVER: 128.186.6.103#53(128.186.6.103)
> ;; WHEN: Fri Oct 10 16:44:51 2003
> ;; MSG SIZE  rcvd: 31
> 
> pamd1:~:131$ dig @128.186.6.103 mktrading.org. +trace
> 
> ; <<>> DiG 9.2.2 <<>> @128.186.6.103 mktrading.org. +trace
> ;; global options:  printcmd
> .                       276543  IN      NS      D.ROOT-SERVERS.NET.
> .                       276543  IN      NS      E.ROOT-SERVERS.NET.
> .                       276543  IN      NS      F.ROOT-SERVERS.NET.
> .                       276543  IN      NS      G.ROOT-SERVERS.NET.
> .                       276543  IN      NS      H.ROOT-SERVERS.NET.
> .                       276543  IN      NS      I.ROOT-SERVERS.NET.
> .                       276543  IN      NS      J.ROOT-SERVERS.NET.
> .                       276543  IN      NS      K.ROOT-SERVERS.NET.
> .                       276543  IN      NS      L.ROOT-SERVERS.NET.
> .                       276543  IN      NS      M.ROOT-SERVERS.NET.
> .                       276543  IN      NS      A.ROOT-SERVERS.NET.
> .                       276543  IN      NS      B.ROOT-SERVERS.NET.
> .                       276543  IN      NS      C.ROOT-SERVERS.NET.
> ;; Received 356 bytes from 128.186.6.103#53(128.186.6.103) in 2 ms
> 
> org.                    172800  IN      NS      TLD1.ULTRADNS.NET.
> org.                    172800  IN      NS      TLD2.ULTRADNS.NET.
> ;; Received 113 bytes from 128.8.10.90#53(D.ROOT-SERVERS.NET) in 24 ms
> 
> MKTRADING.ORG.          172800  IN      NS      NS1.MOOSENET.COM.
> MKTRADING.ORG.          172800  IN      NS      NS2.MOOSENET.COM.
> ;; Received 92 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 33 ms
> 
> mktrading.org.          43200   IN      A       216.98.140.253
> mktrading.org.          43200   IN      NS      ns2.aspadmin.com.
> mktrading.org.          43200   IN      NS      ns3.aspadmin.com.
> mktrading.org.          43200   IN      NS      ns1.aspadmin.com.
> ;; Received 161 bytes from 216.98.155.52#53(NS1.MOOSENET.COM) in 89 ms


	The nameservers do not exist.  Only glue records exist in
	the COM servers.

	On top of that the delegation needs to be updated.

	Mark

; <<>> DiG 8.3 <<>> NS1.MOOSENET.COM aaaa 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;	NS1.MOOSENET.COM, type = AAAA, class = IN

;; AUTHORITY SECTION:
MOOSENET.COM.		2h59m27s IN SOA  NS1.MOOSENET.COM.
scott.MOOSENET.COM. (
					1018238558	; serial
					12H		; refresh
					2H		; retry
					2W		; expiry
					12H )		; minimum


;; Total query time: 1 msec
;; FROM: bsdi.dv.isc.org to SERVER: default -- 127.0.0.1
;; WHEN: Sat Oct 11 10:27:41 2003
;; MSG SIZE  sent: 34  rcvd: 76


; <<>> DiG 8.3 <<>> NS2.MOOSENET.COM aaaa 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;;	NS2.MOOSENET.COM, type = AAAA, class = IN

;; AUTHORITY SECTION:
MOOSENET.COM.		3H IN SOA	ns1.MOOSENET.COM.
scott.MOOSENET.COM. (
					1018238558	; serial
					12H		; refresh
					2H		; retry
					2W		; expiry
					12H )		; minimum


;; Total query time: 206 msec
;; FROM: bsdi.dv.isc.org to SERVER: default -- 127.0.0.1
;; WHEN: Sat Oct 11 10:29:18 2003
;; MSG SIZE  sent: 34  rcvd: 80

> 
> Thanks for getting all the way through the message, Ken
> -- 
>  ---------------------------------------------------------------------
>  Kenneth M. Hays                                hays at acns.fsu.edu 
>  Academic Computing and Network Services        aka kmh8 at the NIC
>  Florida State University                       voice=850-644-2591x129
>  2035 East Paul Dirac Drive                     fax=850-644-8722
>  Tallahassee, Florida 32306-2760                eFax=773-913-0894
>  ---------------------------------------------------------------------
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org

------------------------------

From: Mark_Andrews at isc.org
Subject: Re: DNS Query Format 
Date: Sat, 11 Oct 2003 10:35:40 +1000


> I need the DNS Query and response format at binary level. When a client
> sends a request to a DNS server to resolve a name like yahoo.com, what
> exactly is the format of the data sent using UDP port 53? Also, what is
the
> format of response sent by the server back to the client?
> 
> Keith
> 
> 
	RFC 1034
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org

------------------------------

Date: Sat, 11 Oct 2003 06:45:21 +0400
From: Ladislav Vobr <lvobr at ies.etisalat.ae>
Subject: Re: delegation-only can break .name



Jeremy_Powell at sbcss.k12.ca.us wrote:
> Isn't this what the excludes part of the
> root-delegation-only is meant for.  However,
> I have wondered since the introduction of
> root-delegation-only why it did not default
> to none with an include list rather than
> default to all with an exclude list?

this seems to me to be definitely better approach.

Ladislav



------------------------------

End of bind-users Digest V5 #274
********************************


More information about the bind-users mailing list