karl_kleinpaste@cis.ohio-state.edu (07/18/90)
I know that, periodically, people have a need to fake a top-level domain for one reason or another. No real argument with that; sometimes it seems to make sense. But it becomes a real problem when the bogus information bleeds outside of your own domain. In poking at my nameservers for nic.ddn.mil, the authority section contained the following fascinating set of purported root servers: | For authoritative answers, see: | . 0 IN NS NS.NIC.DDN.MIL | . 0 IN NS NS.NASA.GOV | . 0 IN NS TERP.UMD.EDU | . 0 IN NS A.ISI.EDU | . 0 IN NS AOS.BRL.MIL | . 0 IN NS GUNTER-ADAM.AF.MIL | . 0 IN NS C.NYSER.NET | . 0 IN NS munnari.OZ.AU | . 0 IN NS localhost Ahem. Munnari should not be there, and I assure you that I'm making no attempt to arrogate root server status to myself. The TTLs leave me feeling kinda woozy. Bunches of my nameservers are infected with this information, even some my slave servers doing nothing but serving workstation subnets. All four of my primary nameservers have it; three of those four also have more than one SOA RR for `.'; and one of those has no less than FIVE, two of which are bogons: . 85638 IN SOA NS.NIC.DDN.MIL HOSTMASTER.NIC.DDN.MIL( 900716 ;serial (version) 1800 ;refresh period 300 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) . 68523 IN SOA NS.NIC.DDN.MIL HOSTMASTER.NIC.DDN.MIL( 900712 ;serial (version) 1800 ;refresh period 300 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) . 12367 IN SOA NS.NIC.DDN.MIL HOSTMASTER.NIC.DDN.MIL( 900709 ;serial (version) 1800 ;refresh period 300 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) . 10357 IN SOA Himmelsborg.dna.lth.se hostmaster.sunic.sunet.se( 1990070502 ;serial (version) 28800 ;refresh period 7200 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) . 12562 IN SOA nic.nordu.net hostmaster.nic.nordu.net( 900702 ;serial (version) 28800 ;refresh period 7200 ;retry refresh this often 604800 ;expiration period 86400 ;minimum TTL ) Mental violence manifested before us all. Yowza. If it matters, I'm running UToronto BIND 4.8.2 on assorted Pyramids. Prettyplease, be careful when you do this sort of thing... --karl
kim@lut.fi (Kimmo Suominen) (07/19/90)
>>>>> On 18 Jul 90 13:18:53 GMT, karl_kleinpaste@cis.ohio-state.edu said:
karl> I know that, periodically, people have a need to fake a top-level
karl> domain for one reason or another. No real argument with that;
karl> sometimes it seems to make sense. But it becomes a real problem when
karl> . 12562 IN SOA nic.nordu.net hostmaster.nic.nordu.net(
All this reminds me of a strange thing I was wondering some time ago.
Now that we are connected to the Internet it is impossible to maintain
a system without running DNS (IMHO). However - when you boot up bind
first thing it seems to need is to contact a ROOT name server. When
none are found, bind becomes slow and unco-operative.
Some time ago the link from NordUNet to the Stated was down. I was
really having trouble to get lut.fi running properly - its DNS didn't
know anything - even names it is authoritative for. Well, one problem
was I had forwarders defined and my software (BIND 4.8 port to HP-UX)
has a nasty bug which ends up in an endless loop. After I corrected
that I still had slow downs and name queries took time. To correct
this I got an important piece of advice: add a ROOT name server which
can be reached. I was suggested to add NIC.NORDU.NET to my root
cache. And it helped.
After all this I was left wondering WHY AREN'T THERE ANY ROOT NAME
SERVERS IN EUROPE or Scandinavia? When the links to the precious
servers in the States are down, life becomes (even more) complicated.
Having a ROOT server somewhere nearer would make me feel more secure.
Any good reasons?
--
Kim ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
"That's what ( Kimmo ! Lappeenranta U of Technology ! kim@lut.fi )
*I* think." ( Suominen ! Computing Centre * Finland ! KUULA::KIM )
''''''''''''''''''''''''''''''''''''''''''''''''''''''karl_kleinpaste@cis.ohio-state.edu (07/20/90)
pvm@venera.isi.edu writes:
P.S. Speaking of problems, isn't
pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic
!tut!kannel!kim@tut.cis.ohio-state.edu (Kimmo Suominen)
a bit much? I know, its not your fault, but which postmaster do I
blame?
You blame Erik Fair (sorry, Erik). The newsgate code picks up a
Usenet article and decides it should guarantee an RFC-compliant From:
line as it prepares to distribute to the mailing list side of the
gate. Unfortunately, it chooses to do this by taking the Path: header
(which, in the land of Usenet, is what amounts to an audit trail of
systems where this article has been, to avoid retransmission when
Usenet's flooding algorithm redistributes to neighbors) in !-path
format, and slices/dices/julienne-fries it until it comes out in
something approaching The Right Way.
It flatly ignores the supplied From: line, which is Bad, since in this
case it was the perfectly reasonable
From: kim@lut.fi (Kimmo Suominen)
You'll probably see this note's From: as
From: cis.ohio-state.edu!karl_kleinpaste@tut.cis.ohio-state.edu
even though it'll leave my system as
From: karl_kleinpaste@cis.ohio-state.edu
The reason for hacking up Path: into a From: rather than taking the
supplied From: has to do with the fact that, at least in the past, it
was more than likely that a From: contained some pretty bad addresses,
notably containing UUCP pseudodomain trash (user@host.uucp); so Erik
decided, years ago, to avoid the problem entirely and use Path:. By
now, this decision is probably not in the best of taste, as far more
sites generate valid From: lines. Perhaps I'll see about fixing
newsgate so that it only hacks up Path: if From: contains .uucp. Hm.
--karlsmart@mel.dit.csiro.au (Robert Smart) (07/23/90)
In article <9007191733.AA01412@venera.isi.edu> pvm@venera.isi.edu writes: >Why are there no root servers in Europe? > ... > >The solution is for BIND to stop badgering root servers for no >particular reason: Realistically there are going to be current versions of BIND floating around for a long time. Surely we have to find a solution which may be technically more difficult but which can be enforced centrally. I suggest that each root name server only service a limited constituency of networks. So the root nameservers in Europe would ignore requests from non-European network numbers. Not only that but when they get a request for "." from a European network number then they will only report back with the European root nameservers. I think that with this scheme you could have as many root nameservers as efficiency requires. How do you find out which networks are where? I think the NIC's whois database has the necessary information -- we don't have to get things perfectly optimal. You then inform the owners of the various networks who their root nameservers are. The root nameservers should also handle in-addr.arpa in the same way. And indeed should only answer queries from registered networks. Bob Smart
del@thrush.mlb.semi.harris.com (Don Lewis) (07/25/90)
In article <1990Jul22.233936.2568@mel.dit.csiro.au> smart@mel.dit.csiro.au (Robert Smart) writes: >In article <9007191733.AA01412@venera.isi.edu> pvm@venera.isi.edu writes: >>Why are there no root servers in Europe? >> >... >> >>The solution is for BIND to stop badgering root servers for no >>particular reason: > >Realistically there are going to be current versions of BIND floating >around for a long time. Surely we have to find a solution which may >be technically more difficult but which can be enforced centrally. > >I suggest that each root name server only service a limited constituency >of networks. So the root nameservers in Europe would ignore requests >from non-European network numbers. Not only that but when they get >a request for "." from a European network number then they will only >report back with the European root nameservers. I think that with >this scheme you could have as many root nameservers as efficiency >requires. > This won't work very well either with the current versions of BIND. If my name server queries a European name server for a domain that it is supposed to be authoritative for but isn't, the European server will delegate my server back to the European root servers. It will list the European root name servers in the authority section of the response and their addresses in the additional section. My name server just add these servers to its list of root servers (and pass this information on if it is similarly misconfigured). I have also observered broken name servers responding with the root server list in the authority section just for the heck of it. May I remind everyone that just a few months ago many name servers thought that "GENTER-ADAM.ARPA" was a root server. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
smart@mel.dit.csiro.au (Robert Smart) (07/25/90)
In article <1990Jul25.041622.15179@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: >> >>I suggest that each root name server only service a limited constituency >>of networks. So the root nameservers in Europe would ignore requests >>from non-European network numbers. Not only that but when they get >>a request for "." from a European network number then they will only >>report back with the European root nameservers. I think that with >>this scheme you could have as many root nameservers as efficiency >>requires. >> > >This won't work very well either with the current versions of BIND. >If my name server queries a European name server for a domain that it >is supposed to be authoritative for but isn't, the European server will >delegate my server back to the European root servers. It will list the >European root name servers in the authority section of the response and >their addresses in the additional section. My name server just add these >servers to its list of root servers (and pass this information on if it >is similarly misconfigured). I have also observered broken name servers >responding with the root server list in the authority section just for >the heck of it. May I remind everyone that just a few months ago many >name servers thought that "GENTER-ADAM.ARPA" was a root server. This rather goes with a discussion held some months ago. Name servers shouldn't believe things they hear from non-authoritative sources except as "information of last resort", like the startup cache. Even so this situation won't be drastic. The broken name server will have the European nameservers in its list of root nameservers, but if it tries to use them it will be ignored. I'm sure things would still be a lot better than they are now. In fact packets destined for the European (and Australian!) root nameservers could be dropped by the routers before they leave America (unless from the other root nameservers), so the cost on those most expensive and overloaded links could be nil. Bob Smart <smart@mel.dit.csiro.au>
del@thrush.mlb.semi.harris.com (Don Lewis) (07/26/90)
In article <1990Jul25.054936.25540@mel.dit.csiro.au> smart@mel.dit.csiro.au (Robert Smart) writes: >In article <1990Jul25.041622.15179@mlb.semi.harris.com> del@thrush.mlb.semi.harris.com (Don Lewis) writes: >>> >>>I suggest that each root name server only service a limited constituency >>>of networks. So the root nameservers in Europe would ignore requests >>>from non-European network numbers. Not only that but when they get >>>a request for "." from a European network number then they will only >>>report back with the European root nameservers. I think that with >>>this scheme you could have as many root nameservers as efficiency >>>requires. >>> Also name servers off MILNET should probably not harass the root servers on MILNET. >> >>This won't work very well either with the current versions of BIND. >>If my name server queries a European name server for a domain that it >>is supposed to be authoritative for but isn't, the European server will >>delegate my server back to the European root servers. It will list the >>European root name servers in the authority section of the response and >>their addresses in the additional section. My name server just add these >>servers to its list of root servers (and pass this information on if it >>is similarly misconfigured). I have also observered broken name servers >>responding with the root server list in the authority section just for >>the heck of it. May I remind everyone that just a few months ago many >>name servers thought that "GENTER-ADAM.ARPA" was a root server. > >This rather goes with a discussion held some months ago. Name servers >shouldn't believe things they hear from non-authoritative sources >except as "information of last resort", like the startup cache. Well, the point is that currently available versions of BIND don't behave this way, and even when the fixed version is available we all know how easy it is to get everyone to update there software. >Even >so this situation won't be drastic. The broken name server will have >the European nameservers in its list of root nameservers, but if it >tries to use them it will be ignored. On the surface, it looks like that would cut the traffic by 50%, but in reality the US name servers will just go on to try other root servers, some of which will be European. If a US name server queries two European name servers, we will have just as much traffic as if the first European name server answered in the first place. >I'm sure things would still be a >lot better than they are now. In fact packets destined for the European >(and Australian!) root nameservers could be dropped by the routers before >they leave America (unless from the other root nameservers), so the cost >on those most expensive and overloaded links could be nil. How much will this filtering impact the performance of the routers? -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
ehrlich@cs.psu.edu (Dan &) (07/27/90)
Why not just modify BIND to respect only what the user puts in the named.ca cache file? That way one could put in what one wanted and ignore the rest? -- Dan Ehrlich -- Dan Ehrlich <ehrlich@cs.psu.edu>/Voice: +1 814 863 1142/FAX: +1 814 865 3176
del@thrush.mlb.semi.harris.com (Don Lewis) (07/27/90)
In article <F$wjb271@cs.psu.edu> ehrlich@cs.psu.edu (Dan &) writes: >Why not just modify BIND to respect only what the user puts in the named.ca >cache file? That way one could put in what one wanted and ignore the rest? 1) Because there are so many people out there that don't update their named.ca file. I bet lots of people still have SRI-NIC.ARPA @ 10.0.0.51 listed as a root server. 2) Because name servers sometimes repond with a list of the root servers and all extant versions of BIND take this as gospel, we don't want to propagate the contents of out of date configuration files. This idea would only work if sysadmins kept their configurations up to date, but we know how likely that is. Currently, when BIND starts up, it looks at the root cache file to find out what the root servers are and queries the root servers for the actual list of root servers. It then uses this as its list of root servers (until its cache gets polluted by another name server). This way, if the cache file is good enough for BIND to find at least one real root server it gets the correct list. Hmn, what if BIND only used the intersection between the root cache and the root server response? The only disadvantage that I can think of is that when new root servers are added that they will be underutilized until peoples' configurations catch up. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
david@twg.com (David S. Herron) (07/31/90)
So it's fair to summarize that BIND has a problem in that it returns the same answer to any questioner regardless of where that questioner is. There are many reasons why a site would like to return different answers depending on where the questioner is. For instance: -- Giving out different lists of MX records for hosts on the LAN than is given to hosts outside. Normally MX records are orderd as so: IN MX 0 mail-box-host.dom.ain IN MX 10 near-by-gate.dom.ain IN MX 100 other-gate.dom.ain And this happens to work. But anybody sending mail to the interior domain names will pass through at least one timeout, assuming they aren't allowed to SMTP directly to mail-box-host.dom.ain. This slows down the world needlessly ... -- A different ordering of A records for multi homed hosts depending on where the questioner is. -- Different ordering, or lists of, NS records. etc As I recall there's a mandated syntax/grammar for nameserver information which doesn't allow this stuff to be described. And that BIND is required to follow that grammar. Oh well.. -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
del@thrush.mlb.semi.harris.com (Don Lewis) (07/31/90)
In article <7672@gollum.twg.com> david@twg.com (David S. Herron) writes: >So it's fair to summarize that BIND has a problem in that it >returns the same answer to any questioner regardless of where >that questioner is. > >There are many reasons why a site would like to return different >answers depending on where the questioner is. For instance: > >-- Giving out different lists of MX records for hosts on the LAN > than is given to hosts outside. Normally MX records are orderd > as so: > IN MX 0 mail-box-host.dom.ain > IN MX 10 near-by-gate.dom.ain > IN MX 100 other-gate.dom.ain > And this happens to work. But anybody sending mail to the interior > domain names will pass through at least one timeout, assuming they > aren't allowed to SMTP directly to mail-box-host.dom.ain. This slows > down the world needlessly ... > >-- A different ordering of A records for multi homed hosts depending > on where the questioner is. Actually, there are implementations of the resolver or the local name server that do this already. > >-- Different ordering, or lists of, NS records. > >etc Good summary, BTW. Since name servers pass this information among themselves and some name servers are configured to forward all requests through other name servers, this tends to defeat any schemes that return different information to different clients. The ideal solution would be to supply the client with sufficient information to make the proper decision. Something like a method of determining the "cost" to communicate with the different IP addresses (cheap, expensive, unreachable) would be about right, but it could be very nasty to implement due to the presence of subnets and packet filtering routers. > >As I recall there's a mandated syntax/grammar for nameserver information >which doesn't allow this stuff to be described. And that BIND is >required to follow that grammar. > >Oh well.. > Well, that's what standards buy you 8-(. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901