[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
The need to frequently update small portions of a large zone and to have
those updates propagate ...
> What function, do you think, relaying gives us?
Getting updates through net constrictions such as firewalls.
randy
=========================================================================
Date: Fri, 22 Mar 1996 22:57:54 -0500
Reply-To: "john.p.mcnicholas" <john.p.mcnicholas@AWO.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: "john.p.mcnicholas" <john.p.mcnicholas@AWO.COM>
Subject: Name Server Logic
Does everyone agree with my description of a name server's logic? This name
server happens to be equipped with 4.9.3 and the noforwarders command.
A name server performs the following sequence of events in order to reply to a
query...
1) check all local A (address) records
a) if found, then reply with answer (record found)
- end query
b) if not found then go to step 2
2) compare query to list of domains indicated by noforward command
a) if a match then go to step 3
b) if no match then send a recursive query to the address(es)
listed in the forwarders command
i) if the forwarder responds with an answer (record
found or record not found), then reply accordingly
- end query
ii) if the forwarder does not respond within time
limit, then go to step 3
3) check all local NS (name server) records for the name server
responsible for this domain
a) if a match found then forward query to that name server
i) if that name server responds with an answer (record
found or record not found), then reply accordingly
- end query
ii) if that name server does not respond within time
limit, then go to step 4
b) if no match found then go to step 4
4) forward query to root name server(s)
a) if root responds with answer (record found or record not
found) then reply accordingly - end query
b) if root does not respond within time limit then end query
Thanks,
John
=========================================================================
Date: Fri, 22 Mar 1996 20:24:17 -0800
Reply-To: Paul A Vixie <paul@VIX.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Paul A Vixie <paul@VIX.COM>
Organization: Vixie Enterprises
Subject: Re: forwarding loops in UPDATE
In-Reply-To: randy@PSG.COM's message of 22 Mar 1996 09:04:23 -0800
>> What function, do you think, relaying gives us?
>
>Getting updates through net constrictions such as firewalls.
Odd. That's important but it wasn't the reason forwarding was added.
A zone slave ("secondary") knows the name of a server which is the
primary master, or is closer to the primary master than the current
zone slave. Further, we know that there is no permanent or common
network partition between a zone slave and its source of AXFR.
If a requestor had to locate the real primary master, we would have
to require the SOA MNAME to be that master, rather than just "the
source of the data" which could mean ftp or paper tape or whatever.
The primary master would also have to be reachable from everywhere.
The last part is the common "firewall" argument. The earlier part
is more important, though. SOA MNAME is only a DNS server if it is
also an NS NSDNAME.
Therefore in the absence of forwarding, all requestors would have to
potentially try all NS RRs in search of a primary master. The primary
master would have to be listed in the NS RRset. This combination of
overspecification of primary masters and inefficiency of locating the
primary master via iteration was the real reason why forwarding was
added. The fact that it solves the firewall problem was useful but not
by itself a deciding factor.
The alternative to this is adding a new RR type to denote the zone's
updator, and we went all through this in Danvers.
Forwarding is at this point not a bolt-on, it's integral to the way
the DNS UPDATE proposal works. We can't change it trivially.
Arguments of the form, "forwarding is bad since it hides the source IP
address of the requestor" are nonsequitur. The UPDATE draft does not
specify security of any kind, especially not security based on the IP
source address. I have heard no argument that forwarding makes UPDATE
less secure, and I don't expect to hear one since UPDATE IS NOT SECURE.
Let's move on.
--
Paul Vixie
La Honda, CA "Illegitimibus non carborundum."
<paul@vix.com>
pacbell!vixie!paul
=========================================================================
Date: Sat, 23 Mar 1996 15:51:20 +1100
Reply-To: Robert Elz <kre@MUNNARI.OZ.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Robert Elz <kre@MUNNARI.OZ.AU>
Subject: Re: New serial number draft
X-To: namedroppers@internic.net
In-Reply-To: Your message of "Fri, 22 Mar 1996 06:35:00 PST."
<m0u07w0-00080IC@rip.psg.com>
Date: Fri, 22 Mar 1996 06:35:00 PST
From: Randy Bush <randy@PSG.COM>
Message-ID: <m0u07w0-00080IC@rip.psg.com>
which of the other 'side' drafts are ready for WG last call?
Neither yet, I have been deliberately not hurrying them.
I know you (Randy) said not to delay them beyond Apr 15 just
for the sake of delaying them, but doing so avoids excess
extraneous stuff on the list, and also allows me to do some
other work in the meantime.
i.e. which are you not planning another edition?
Both. I have a bunch of revisions (additions mostly) to
the secondary server draft done that I need to reread, then
send you (Randy) to read, then sometime later send to the
i-d directories.
There are also a bunch of changes to the clarify draft that
came from LA, that I have yet to edit into the sources.
As I said, I'm not really hurrying this stuff...
I'm also not sure if I should send in yet another serial draft,
Randy pointed out that I omitted his address from the Author's
address section that I added (which I added purely because
someone else complained about some other draft I think -
personally I'm not sure that Author's address makes sense in
docs which are nominally working group output, as opposed to
random submissions to the RFC Editor). That can be added
when it turns into an RFC if no-one minds it not being there
in this draft (speak up soon if you need to see this in the I-D
that goes through WG last call...)
Also, I had a note from LA to add a ref to Hosts Requirements
in this draft (that is, to 1123). I'm not sure why I made that
note. I reviewed the HR section on the DNS again, and couldn't
see anything even slightly relevant to serial numbers. If
anyone wants I can easily add a ref to 1123, but not reference
it anywhere (an unreferenced reference), just so it appears in
the refs list - if anyone wants it really referenced (ie: the
text makes soem reference to it), you'll need to tell me what
you want said about it. Of course, that note I made may have
been simply my brain sleeping somewhere, and no HR ref is needed
here at all, which is what I prefer.
kre
=========================================================================
Date: Sat, 23 Mar 1996 14:50:10 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: forwarding loops in UPDATE
X-To: Randy Bush <randy@psg.com>
X-cc: namedroppers@internic.net
In-Reply-To: <m0u092n-00080IC@rip.psg.com>; from "Randy Bush" at Mar 22,
96 7:46 am
Randy;
Could you elaborate on what you think a problem when removing
the forwarding feature?
> > If we allow TCP/53 for ANY secondary which forwards update
> > requests, the forwarded request will have IP address of the
> > secondary and there will be no security.
>
> s/no security/exposure to port 53 attacks from the IP addresses of the
> secondaries from which we will accept forwarded update requests/
I'm afraid there is misunderstanding.
"ANY" in my message means "at least one" forwarding secondary
recognized by a firewall administrator.
Then, UPDATE request from some IP address will be forwarded
with the IP address of the recognized secondary and there
will be no weak security.
> > On the otherhand, if we don't allow forwarding, we can allow
> > TCP,UDP/53 holes purely for zone transfer between the primary and
> > secondaries (not necessarily all secondaries, because zone
> > transfer can be relayed). There may be other holes allowed for
> > dynamic update directly between the primary and updaters.
>
> But, given the laptop analogy, that requires allowing the port 53 update
> hole for *any* address. This seems much less secure than the forwarding
> solution.
What is "the laptop analogy"?
> Surely I am misunderstanding you. Sorry.
Seemingly.
Without forwarding, source IP address of UPDATE is preserved.
So, the primary can filter requests from it's source IP addresses,
if a local administrator think weak security is secure enough for
that addresses (because of another firewall or because the trusted
IP address belongs to the same local trusted provider or any other
reason).
Of course, the local administrator may
allow any updater communicate with the primary
allow no updater outside of the firewall communicate with the primary
allow specific updaters outside of the firewall communicate
with the primary
They are all local options.
And, this is the current practice of weak security and firewall
administration.
> o not providing forwarding of updates?
>
> If you suggest the latter choice, then you must supply a solution to the
> firewall problem.
Could you elaborate on what is "the firewall problem"?
> >>> 2) forwarding is firewall unfriendly
> >> I.e. it is an attempt to get data through a firewall at the application
> >> level as opposed to punching an IP layer hole?
> > Application level firewall needs no specification (usually depends
> > on weak security) or have it's own protocol for firewall penetration.
>
> I suspect the dynamic forwarding part of the update draft is an attempt at
> the latter.
See psuedo code in the draft to know THE (according to Paul) point
where permission checking is specified to be done.
You can also check where the forwarding should be performed.
Zone slaves are explicitely specified to forward update requests
without permission checking.
BTW, though I don't think it a serious problem, Paul's draft impose
too much of his intention and is rather an implementation note
than a protocol description.
> >From the WG charter
>
> The need to frequently update small portions of a large zone and to have
> those updates propagate ...
OK.
> > What function, do you think, relaying gives us?
>
> Getting updates through net constrictions such as firewalls.
I think you misunderstand firewall issues and I need detailed
explanation.
Can you or someone else give us examples of non-firewall
constrictions over which UPDATE should be operational?
Masataka Ohta
=========================================================================
Date: Fri, 22 Mar 1996 22:05:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: Re: forwarding loops in UPDATE
X-To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
X-cc: namedroppers@internic.net
Masataka:
I think I now understand your point. You dislike that the origin of the
update is not known by the primary if it has been forwarded by a secondary.
Personally, I am not too concerned. If we want security, Donald's draft
will be the way to go. In that case, the request will authenticate by key,
not by address. This seems far less spoofable.
randy
=========================================================================
Date: Sat, 23 Mar 1996 15:15:17 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: forwarding loops in UPDATE
X-To: Randy Bush <randy@psg.com>
X-cc: namedroppers@internic.net
In-Reply-To: <m0u0MSD-000801C@rip.psg.com>; from "Randy Bush" at Mar 22,
96 10:05 pm
> I think I now understand your point. You dislike that the origin of the
> update is not known by the primary if it has been forwarded by a secondary.
>
> Personally, I am not too concerned. If we want security, Donald's draft
> will be the way to go. In that case, the request will authenticate by key,
> not by address. This seems far less spoofable.
That's a contradition.
As long as people use firewalls, firewalls should not be penetrated
lightly. That is, the current forwarding feature is wrong.
If people don't use firewalls, The current forwarding feature is
unnecessary.
That is, we shouldn't make protocols firewall hostile only because
someone promised sure security.
There are a lot of reasons, legal, operational and others, why sure
security is not available.
Masataka Ohta
=========================================================================
Date: Sat, 23 Mar 1996 15:57:22 JST
Reply-To: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Masataka Ohta <mohta@NECOM830.HPCL.TITECH.AC.JP>
Subject: Re: forwarding loops in UPDATE
X-To: paul@VIX.COM
In-Reply-To: <VIXIE.96Mar22202415@wisdom.vix.com>; from "Paul A Vixie" at Mar
22, 96 8:24 pm
> >> What function, do you think, relaying gives us?
> >
> >Getting updates through net constrictions such as firewalls.
>
> Odd. That's important but it wasn't the reason forwarding was added.
> A zone slave ("secondary") knows the name of a server which is the
> primary master, or is closer to the primary master than the current
> zone slave. Further, we know that there is no permanent or common
> network partition between a zone slave and its source of AXFR.
>
> If a requestor had to locate the real primary master,
Geg. Are you proposing to have "a real primary master" and
"a psuedo primary master"?
> we would have
> to require the SOA MNAME to be that master, rather than just "the
> source of the data" which could mean ftp or paper tape or whatever.
First of all, you define that "the primary master" is located at the
AXFR/IXFR dependency graph.
Moreover, according to the charter:
Dynamic Update - The need to frequently update small portions of a
^^^^^^^^^^
large zone and to have those updates propagate is perceived.
I don't think paper tape transport allows frequent enough update.
Considering that many think "frequently" means hundreds or thousnads
of updates a second, even ftp won't be fast enough.
BTW, what information, do you think, can be transported with ftp?
Unless we have some IXFR/UPDATE equivalent for fpt, rather
than ASCII transfer of full zone files, UPDATE is assured
to be slow.
> The primary master would also have to be reachable from everywhere.
Which primary master? A real one or a psuedo one?
A psuedo one should be reachable from every updaters (but not
necessarily from everywhere).
A psuedo one may still use any quick transport to reach a real one.
> Therefore in the absence of forwarding, all requestors would have to
> potentially try all NS RRs in search of a primary master.
You think it matters.
Without forwarding, requestors try to get the current most SOA
with normal query (specified in "/etc/resolve.conf") and, in a
rare event (with NOTIFY, it is assured to be negligibly rare)
when the primary changes but it's change is not propagated yet,
an UPDATE request may (or may not) fail.
On the other hand, with your current spec, all requestors would
have to potentially try all NS RRs to try to find a one which
forward request to a real primary master.
So, you should drop forwarding feature.
> The primary
> master would have to be listed in the NS RRset.
FC 1035 requires that the MNAME must be a name server. If it is
not one of an NS, it should be warned.
But, to reach the primary, the primary does not have to be
listed in the NS RRset. A updater knows the name of the primary
from SOA and ask it's A with a normal query. The updater won't
know whether the primary is in the NS set or not.
> The alternative to this is adding a new RR type to denote the zone's
> updator, and we went all through this in Danvers.
What is "this"? Just remove forwarding and everything works.
> Forwarding is at this point not a bolt-on, it's integral to the way
> the DNS UPDATE proposal works. We can't change it trivially.
The idea of the primary is integral to the DNS and you can't
change it trivially.
It's only that you thought:
there are real and psuedo primary masters
a real primary may use paper tape transport for dymanic update
with forwarding, updaters don't have to try all secondaries
without forwarding, finding the primary is difficult
without forwarding, the primary must be listed in NS
all of which are trivial misunderstanding and many of which
contradicts with your own draft.
Masataka Ohta
=========================================================================
Date: Sat, 23 Mar 1996 08:09:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: WG last call on draft-ietf-dnsind-serial-02.txt
X-To: namedroppers <namedroppers@internic.net>
Please consider this the WG last call on draft-ietf-dnsind-serial-02, which
is in the internet-drafts directory now.
Robert will submit a version with both authors' addresses after the WG last
call is done, so it can be that one that we ask the IESG to advance.
randy
=========================================================================
Date: Mon, 25 Mar 1996 09:54:20 -0500
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
Comments: RFC822 error: <W> Incorrect or incomplete address field found and
ignored.
From: Internet-Drafts@CNRI.RESTON.VA.US
Subject: I-D ACTION:draft-ietf-dnsind-serial-02.txt
X-cc: namedroppers@internic.net
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : Serial Number Arithmetic
Author(s) : R. Elz, R. Bush
Filename : draft-ietf-dnsind-serial-02.txt
Pages : 8
Date : 03/22/1996
This draft defines serial number arithmetic, as used in the Domain Name
System. The DNS has long relied upon serial number arithmetic, a concept
which has never really been defined, certainly not in an IETF document,
though which has been widely understood. This draft supplies the missing
definition. It is intended to update RFC1034 and RFC1035.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-serial-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-serial-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv@ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-serial-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ds.internic.net"
Content-Type: text/plain
Content-ID: <19960322143408.I-D@CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-serial-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-serial-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960322143408.I-D@CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
=========================================================================
Date: Wed, 27 Mar 1996 02:40:35 GMT
Reply-To: William Allen Simpson <bsimpson@MORNINGSTAR.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: William Allen Simpson <bsimpson@MORNINGSTAR.COM>
Subject: How can this happen???
The most mind boggling thing happened to my email repository yesterday,
and it's still not fixed 24 hours later....
The Internic says there are two nameservers for greendragon.com. Those,
in turn, are supposed to be getting from the master, ns.watervalley.net.
Instead, one of them is just reporting the Internic specified NS records
(no zone), and the other is giving out completely bogus information!!!
Including a deliberate mail loop to 127.0.0.1!!!
Is there any way for this to happen naturally???
Is this a known security problem??? Will DNS Sec solve this kind of
configuration problem?
----
sashimi.wwa.com says:
Recording Wed Mar 27 02:11:52 1996
dns_query: querying server 198.49.174.1 for greendragon.com.
response id 46091 (rtt 0 sec) qr 1 opcode 0 aa 0 tc 0 rd 1 ra 1 rcode 0
1 questions:
greendragon.com. type {255} class 1
2 answers:
greendragon.com. 64294 IN NS SASHIMI.WWA.COM.
greendragon.com. 64294 IN NS DNS.CHI.IL.US.
2 authority:
greendragon.com. 64294 IN NS SASHIMI.WWA.COM.
greendragon.com. 64294 IN NS DNS.CHI.IL.US.
2 additional:
SASHIMI.WWA.COM. 172800 IN A 198.49.174.1
DNS.CHI.IL.US. 484898 IN A 198.147.221.40
----
dns.chi.il.us says:
Recording Wed Mar 27 02:05:58 1996
dns_query: querying server 198.147.221.40 for greendragon.com.
response id 19870 (rtt 0 sec) qr 1 opcode 0 aa 1 tc 0 rd 1 ra 1 rcode 0
1 questions:
greendragon.com. type {255} class 1
4 answers:
greendragon.com. 172800 IN NS dns.chi.il.us.
greendragon.com. 172800 IN NS dns2.chi.il.us.
greendragon.com. 172800 IN SOA dns.chi.il.us. postmaster.dns.chi.il.us. 2 86400 18000 2592000 172800
greendragon.com. 172800 IN MX 100 bogushost.greendragon.com.
2 authority:
greendragon.com. 172800 IN NS dns.chi.il.us.
greendragon.com. 172800 IN NS dns2.chi.il.us.
3 additional:
dns.chi.il.us. 604800 IN A 198.147.221.40
dns2.chi.il.us. 86400 IN A 204.248.239.42
bogushost.greendragon.com. 172800 IN A 127.0.0.1
----
The Primary Master ns.watervalley.net says:
Recording Wed Mar 27 02:17:46 1996
dns_query: querying server 204.248.173.2 for greendragon.com.
response id 6811 (rtt 0 sec) qr 1 opcode 0 aa 1 tc 0 rd 1 ra 1 rcode 0
1 questions:
greendragon.com. type {255} class 1
5 answers:
greendragon.com. 3600 IN SOA ns.watervalley.net. hshere@watervalley.net. 601 1800 300 72000 3600
greendragon.com. 999999 IN NS ns.watervalley.net.
greendragon.com. 3600 IN NS sashimi.wwa.com.
greendragon.com. 3600 IN A 204.248.173.2
greendragon.com. 3600 IN A 204.248.173.128
0 authority:
3 additional:
sashimi.wwa.com. 170549 IN A 198.49.174.1
greendragon.com. 3600 IN A 204.248.173.2
greendragon.com. 3600 IN A 204.248.173.128
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
=========================================================================
Date: Wed, 27 Mar 1996 15:23:11 +1100
Reply-To: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Mark Andrews <Mark.Andrews@DMS.CSIRO.AU>
Subject: Re: How can this happen???
X-To: William Allen Simpson <bsimpson@morningstar.com>
In-Reply-To: Your message of "Wed, 27 Mar 1996 02:40:35 GMT."
<5151.bsimpson@morningstar.com>
> The most mind boggling thing happened to my email repository yesterday,
> and it's still not fixed 24 hours later....
>
> The Internic says there are two nameservers for greendragon.com. Those,
> in turn, are supposed to be getting from the master, ns.watervalley.net.
>
> Instead, one of them is just reporting the Internic specified NS records
> (no zone), and the other is giving out completely bogus information!!!
> Including a deliberate mail loop to 127.0.0.1!!!
>
> Is there any way for this to happen naturally???
>
> Is this a known security problem??? Will DNS Sec solve this kind of
> configuration problem?
>
> ----
>
> sashimi.wwa.com says:
>
> Recording Wed Mar 27 02:11:52 1996
> dns_query: querying server 198.49.174.1 for greendragon.com.
> response id 46091 (rtt 0 sec) qr 1 opcode 0 aa 0 tc 0 rd 1 ra 1 rcode 0
> 1 questions:
> greendragon.com. type {255} class 1
> 2 answers:
> greendragon.com. 64294 IN NS SASHIMI.WWA.COM.
> greendragon.com. 64294 IN NS DNS.CHI.IL.US.
> 2 authority:
> greendragon.com. 64294 IN NS SASHIMI.WWA.COM.
> greendragon.com. 64294 IN NS DNS.CHI.IL.US.
> 2 additional:
> SASHIMI.WWA.COM. 172800 IN A 198.49.174.1
> DNS.CHI.IL.US. 484898 IN A 198.147.221.40
>
> ----
>
> dns.chi.il.us says:
>
> Recording Wed Mar 27 02:05:58 1996
> dns_query: querying server 198.147.221.40 for greendragon.com.
> response id 19870 (rtt 0 sec) qr 1 opcode 0 aa 1 tc 0 rd 1 ra 1 rcode 0
> 1 questions:
> greendragon.com. type {255} class 1
> 4 answers:
> greendragon.com. 172800 IN NS dns.chi.il.us.
> greendragon.com. 172800 IN NS dns2.chi.il.us.
> greendragon.com. 172800 IN SOA dns.chi.il.us. postmast
> er.dns.chi.il.us. 2 86400 18000 2592000 172800
> greendragon.com. 172800 IN MX 100 bogushost.greend
> ragon.com.
> 2 authority:
> greendragon.com. 172800 IN NS dns.chi.il.us.
> greendragon.com. 172800 IN NS dns2.chi.il.us.
> 3 additional:
> dns.chi.il.us. 604800 IN A 198.147.221.40
> dns2.chi.il.us. 86400 IN A 204.248.239.42
> bogushost.greendragon.com. 172800 IN A 127.0.0.1
>
> ----
>
> The Primary Master ns.watervalley.net says:
>
> Recording Wed Mar 27 02:17:46 1996
> dns_query: querying server 204.248.173.2 for greendragon.com.
> response id 6811 (rtt 0 sec) qr 1 opcode 0 aa 1 tc 0 rd 1 ra 1 rcode 0
> 1 questions:
> greendragon.com. type {255} class 1
> 5 answers:
> greendragon.com. 3600 IN SOA ns.watervalley.net.
> hshere@watervalley.net. 601 1800 300 72000 3600
> greendragon.com. 999999 IN NS ns.watervalley.net.
> greendragon.com. 3600 IN NS sashimi.wwa.com.
> greendragon.com. 3600 IN A 204.248.173.2
> greendragon.com. 3600 IN A 204.248.173.128
> 0 authority:
> 3 additional:
> sashimi.wwa.com. 170549 IN A 198.49.174.1
> greendragon.com. 3600 IN A 204.248.173.2
> greendragon.com. 3600 IN A 204.248.173.128
>
>
> WSimpson@UMich.edu
> Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
> BSimpson@MorningStar.com
> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
>
Well first thing I would do is fix 204.248.173.2. It definitly
is NOT running a modern nameserver. Two authorative SOA
records!
Mark
; <<>> DiG 2.0 <<>> soa greendragon.com @204.248.173.2
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd ra; Ques: 1, Ans: 2, Auth: 0, Addit: 0
;; QUESTIONS:
;; greendragon.com, type = SOA, class = IN
;; ANSWERS:
greendragon.com. 3600 SOA ns.watervalley.net. hshere@watervalley.net. (
601 ; serial
1800 ; refresh (30 mins)
300 ; retry (5 mins)
72000 ; expire (20 hours)
3600 ) ; minimum (1 hour)
greendragon.com. 172800 SOA sashimi.wwa.com. postmaster.sashimi.wwa.com. (
96032619 ; serial
86400 ; refresh (1 day)
18000 ; retry (5 hours)
2592000 ; expire (30 days)
172800 ) ; minimum (2 days)
;; Total query time: 395 msec
;; FROM: pride.syd.dms.CSIRO.AU to SERVER: 204.248.173.2
;; WHEN: Wed Mar 27 15:18:18 1996
;; MSG SIZE sent: 33 rcvd: 168
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au
MOBIL: +61 41 942 8884 UUCP:....!uunet!syd.dms.csiro.au!marka
=========================================================================
Date: Tue, 26 Mar 1996 21:05:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: Re: How can this happen???
X-To: William Allen Simpson <bsimpson@MORNINGSTAR.COM>
X-cc: namedroppers <namedroppers@internic.net>
Of the listed servers,
o sashimi.wwa.com does not carry the zone file at all
o dns.chi.il.us does not carry the zone file at all
I.e. the zone is not being served at all. Welcome to classic bogusville.
If you need servers, holler. But tell us what the content of the zone
should be, and in the next few hours before I do the metal bird again.
randy
to look at it from doc's point of view
rip:/home/randy> doc -w -p greendragon.com.
Doc-2.1.1: doc -w -p greendragon.com.
Doc-2.1.1: Starting test of greendragon.com. parent is com.
Doc-2.1.1: Test date - Tue Mar 26 21:03:55 PST 1996
ERROR: no SOA record for greendragon.com. from dns.chi.il.us.
ERROR: no SOA record for greendragon.com. from sashimi.wwa.com.
SYSerr: No servers for greendragon.com. returned SOAs ...
Summary:
YIKES: doc aborted while testing greendragon.com. parent com.
ERRORS found for greendragon.com. (count: 2)
Incomplete test for greendragon.com. (1)
Done testing greendragon.com. Tue Mar 26 21:04:00 PST 1996
or piece by piece.
rip:/home/randy> dig +norec @a.root-servers.net. greendragon.com. ns
; <<>> DiG 2.1 <<>> +norec @a.root-servers.net. greendragon.com. ns
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr; Ques: 1, Ans: 2, Auth: 0, Addit: 1
;; QUESTIONS:
;; greendragon.com, type = NS, class = IN
;; ANSWERS:
greendragon.com. 172800 NS DNS.CHI.IL.US.
greendragon.com. 172800 NS SASHIMI.WWA.COM.
;; ADDITIONAL RECORDS:
SASHIMI.WWA.COM. 172800 A 198.49.174.1
;; Total query time: 157 msec
;; FROM: rip.psg.com to SERVER: a.root-servers.net. 198.41.0.4
;; WHEN: Tue Mar 26 21:02:20 1996
;; MSG SIZE sent: 33 rcvd: 105
rip:/home/randy> dig +norec @SASHIMI.WWA.COM. greendragon.com. soa
; <<>> DiG 2.1 <<>> +norec @SASHIMI.WWA.COM. greendragon.com. soa
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr ra; Ques: 1, Ans: 0, Auth: 9, Addit: 19
;; QUESTIONS:
;; greendragon.com, type = SOA, class = IN
;; AUTHORITY RECORDS:
. 516852 NS F.ROOT-SERVERS.NET.
. 516852 NS G.ROOT-SERVERS.NET.
. 516852 NS A.ROOT-SERVERS.NET.
. 516852 NS H.ROOT-SERVERS.NET.
. 516852 NS B.ROOT-SERVERS.NET.
. 516852 NS C.ROOT-SERVERS.NET.
. 516852 NS D.ROOT-SERVERS.NET.
. 516852 NS E.ROOT-SERVERS.NET.
. 516852 NS I.ROOT-SERVERS.NET.
;; ADDITIONAL RECORDS:
F.ROOT-SERVERS.NET. 603252 A 192.5.5.241
F.ROOT-SERVERS.NET. 385090 A 39.13.229.241
F.ROOT-SERVERS.NET. 157777 A 128.8.10.90
G.ROOT-SERVERS.NET. 516852 A 192.112.36.4
A.ROOT-SERVERS.NET. 596333 A 198.41.0.4
A.ROOT-SERVERS.NET. 372846 A 198.57.0.4
H.ROOT-SERVERS.NET. 593451 A 128.63.2.53
H.ROOT-SERVERS.NET. 536536 A 128.63.0.53
B.ROOT-SERVERS.NET. 596937 A 128.9.0.107
C.ROOT-SERVERS.NET. 593075 A 192.33.4.12
D.ROOT-SERVERS.NET. 596333 A 128.8.10.90
D.ROOT-SERVERS.NET. 486814 A 192.5.5.241
D.ROOT-SERVERS.NET. 304891 A 128.8.10.88
D.ROOT-SERVERS.NET. 512837 A 128.8.65.87
E.ROOT-SERVERS.NET. 593075 A 192.203.230.10
E.ROOT-SERVERS.NET. 159123 A 224.203.230.10
E.ROOT-SERVERS.NET. 88660 A 192.201.230.10
E.ROOT-SERVERS.NET. 223300 A 192.203.228.10
E.ROOT-SERVERS.NET. 74582 A 192.203.230.26
;; Total query time: 285 msec
;; FROM: rip.psg.com to SERVER: SASHIMI.WWA.COM. 198.49.174.1
;; WHEN: Tue Mar 26 20:54:08 1996
;; MSG SIZE sent: 33 rcvd: 488
rip:/home/randy> dig +norec @DNS.CHI.IL.US. greendragon.com. soa
; <<>> DiG 2.1 <<>> +norec @DNS.CHI.IL.US. greendragon.com. soa
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10
;; flags: qr ra; Ques: 1, Ans: 0, Auth: 0, Addit: 0
;; QUESTIONS:
;; greendragon.com, type = SOA, class = IN
;; Total query time: 254 msec
;; FROM: rip.psg.com to SERVER: DNS.CHI.IL.US. 198.147.221.40
;; WHEN: Tue Mar 26 20:52:26 1996
;; MSG SIZE sent: 33 rcvd: 33
=========================================================================
Date: Wed, 27 Mar 1996 08:39:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: draft-ietf-dnsind-dynDNS-09.txt
X-To: conf@sol.eg.bucknell.edu
X-cc: namedroppers <namedroppers@internic.net>
DCHers:
The dnsing WG needs to go to last call on draft-ietf-dnsind-dynDNS-09.txt,
the dynamic update draft, on Monday or the draft will die.
Is the dhc WG satisfied that the current draft will meet dhc's needs for the
next couple of years, by whatever criterion you choose?
Thank you for your constructive help.
randy
=========================================================================
Date: Wed, 27 Mar 1996 16:57:55 -0500
Reply-To: Tom Newell <tomn@INTERNIC.NET>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Tom Newell <tomn@INTERNIC.NET>
Subject: Zone file update schedule change
X-To: rs-info@internic.net
X-cc: namedroppers@internic.net
FYI
Change to the root zones update schedule:
The zone file updates have occurred on Monday, Wednesday, and Friday
each week. Beginning April 8, 1996, the InterNIC will release the
root zones 5 days a week (Monday through Friday) by 10 PM (EST)
each day.
Tom
--
Tom Newell liaison@internic.net +1 703 742 4796
NIC Liaison InterNIC Support Services
PGP Key fingerprint = 5E 86 3D 13 73 19 69 08 6B 54 6A 7D AD A2 37 6D
=========================================================================
Date: Thu, 28 Mar 1996 22:58:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: WG last call on draft-ietf-dnsind-dynDNS-09.txt
X-To: namedroppers <namedroppers@internic.net>
X-cc: inads@research.ftp.com
Please consider this the WG last call on draft-ietf-dnsind-dynDNS-09.txt.
The dhc WG has said that they will accept stale RRs for a few years and see
if it becomes a problem.
randy
=========================================================================
Date: Thu, 28 Mar 1996 23:05:00 PST
Reply-To: Randy Bush <randy@PSG.COM>
Sender: Owner-Namedroppers <owner-namedroppers@internic.net>
From: Randy Bush <randy@PSG.COM>
Subject: current last call status
X-To: namedroppers <namedroppers@internic.net>
X-cc: inads@research.ftp.com
draft-ietf-dnsind-ixfr-06.txt is in IESG last call and will need to
be reactivated
draft-ietf-dnsind-notify-07.txt started WG last call on 960318
draft-ietf-dnsind-serial-02.txt started WG last call on 960323
draft-ietf-dnsind-dynDNS-09.txt started WG last call on 960328
KRE, want to throw the others into the bin so we can close this all out?
randy