What kind of address is '3483043927' ?
Tal Dayan
tal at zapta.com
Sat Aug 12 02:59:57 UTC 2000
I got today a spam message that includes the link http://3483043927/
What kind of host spec is '3483043927' ? It is not in the top
domains (e.g. .com) and is not an IP address in dot
notation (e.g. 1.2.3.4). I have never seen anything like that
before.
Thanks,
Tal
> -----Original Message-----
> From: kcd at daimlerchrysler.com [mailto:kcd at daimlerchrysler.com]
> Sent: Friday, August 11, 2000 3:08 PM
> To: bind-users at isc.org
> Subject: Re: "Extra" NS on zone file can be used?
>
>
>
> I can't locate a copy of the FAQ to which you refer, but the part
> you quoted sounds just
> plain wrong. The NS records of the zone, which are returned in
> the Authority Section of
> responses, have higher "credibility" than the delegation NS
> records, and must therefore
> *REPLACE* the delegation NS'es, according to Section 5.4.1 of RFC
> 2181. This is why it's
> so important for the NS'es in the zone to be correct and
> functional, and to be identical
> to, or a subset of the delegation NS'es (see the recent
> discussion involving Mark Andrews
> and myself, on this topic). So the simple answer is yes, if you
> put an NS in the zone,
> other nameservers will attempt to use it.
>
> I'm not sure what the best way would be of implementing your
> hidden-master scenario.
> Hacking nsupdate should be considered a last resort. Why not put
> one of the slave's names
> in the MNAME and arrange to have it resolve to the master's
> address only in your
> *internal* DNS? The world would think that that slave is the
> master, but you'd know
> better...
>
>
> - Kevin
>
> Jesus Couto wrote:
>
> > Hi,
> >
> > I have read in a few places (for example, Question 2.17 of the
> > comp.protocols.tcp-ip.domains FAQ) that the NS records for a zone
> > defined inside the zone file arent really used... again from the FAQ:
> >
> > "They're essentially unused, though they are returned in the authority
> > section of reply packets from your name servers"
> >
> > So, lets say I add a NS record inside, say, "test" zone
> file listing
> > "dada.ext" as
> > a nameserver for it. A query for a name inside test (say, a.test) will
> > return the NS as listed in the zone file. It will cause the server to
> > fetch the A record for "dada.ext", and the next query into "test" will
> > have that address into the Additional Info section of the answer. (All
> > this checked using nslookup at d2 level and query logging on the "ext"
> > server, but I may be wrong).
> >
> > So, then, the server that did the second query into
> test will have the
> > full list of NS as listed in the zone file and the address for all of
> > them in the cache, right? And that means that on further queries from
> > that server, the "extra" server will be used for some of them, right?
> > Thats what I'm thinking, but as it contradicts whats the FAQ states, I
> > want some confirmation.
> >
> > All this comes from playing with nsupdate and hidden
> masters... because
> > a) the server only does the updates if its listed as the MNAME on the
> > SOA of the zone and b) nsupdate only sends the updates to the MNAME
> > server if its also a NS for the zone, I thought that, to have a hidden
> > master, we could list the "real" server, on a private IP net and a
> > private domain, on the NS of the zone file. Ex.:
> >
> > $ORIGIN mypublicdomain.com
> >
> > 82400 IN SOA master.priv. root.mypublicdomain.com. (
> > 2 1000 1000 1000 7200 )
> > 82400 IN NS ns1.mypublicdomain.com.
> > 82400 IN NS ns2.mypublicdomain.com.
> > 82400 IN NS master.priv.
> >
> > but if at the end this means that the public servers ns1 and ns2 are
> > going to start propagating that master.priv is an NS for
> > mypublicdomain.com and giving away its private IP, then making servers
> > on the internet to try to query that when doing lookups into
> > mypublic.domain.com, its going to be ugly. (In any case, to solve this,
> > I'm either going to use the perl Net::DNS module or rewrite nsupdate or
> > the resolver lib to send queries to a given server instead of using the
> > NS listed at the zone).
> >
> > So, its this analysis right, and "extra" NS on the zone
> files will be
> > used by external nameservers? Its then necessary to list as NS on a
> > public zone only public, reachable nameservers?
> >
> > Thanks in advance to whoever steps in and clarify this
> issue for me;
> >
> >
> Jesus Couto F.
>
>
>
>
>
>
More information about the bind-users
mailing list