Sitll doesn't work: ; <<>> DiG 2.2 <<>> www.dvv.ru. @c.root-servers.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ^^^^^^^^ ;; flags: qr aa rd; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ^^ ;; QUESTIONS: ;; www.dvv.ru, type = A, class = IN ;; AUTHORITY RECORDS: . 86400 SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( 1997010200 ; serial 10800 ; refresh (3 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ;; Total query time: 94 msec ;; FROM: tigger.sprintlink.net to SERVER: c.root-servers.net 192.33.4.12 ;; WHEN: Fri Jan 3 15:39:41 1997 ;; MSG SIZE sent: 28 rcvd: 101 when the correct response should be ; <<>> DiG 2.2 <<>> www.dvv.ru. @a.root-servers.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 6, Addit: 6 ;; QUESTIONS: ;; www.dvv.ru, type = A, class = IN ;; AUTHORITY RECORDS: RU. 172800 NS NS.RELCOM.EU.NET. RU. 172800 NS NS.EU.NET. RU. 172800 NS SUNIC.SUNET.SE. RU. 172800 NS NS.UU.NET. RU. 172800 NS NS2.NIC.FR. RU. 172800 NS SPARKY.ARL.MIL. ;; ADDITIONAL RECORDS: NS.RELCOM.EU.NET. 172800 A 193.124.23.3 NS.EU.NET. 172800 A 192.16.202.11 SUNIC.SUNET.SE. 172800 A 192.36.125.2 SUNIC.SUNET.SE. 172800 A 192.36.148.18 NS.UU.NET. 172800 A 137.39.1.3 NS2.NIC.FR. 172800 A 192.93.0.4 ;; Total query time: 132 msec ;; FROM: tigger.sprintlink.net to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Fri Jan 3 15:40:12 1997 ;; MSG SIZE sent: 28 rcvd: 273 I suggest you bring it off the net until the problem is fixed - its current behaviour disrupts the Internet's functioning on the global scale. Thanks Dima libby@support.psi.com writes:

Hi,

This has been fixed. We are investigating why this failure did not raise an alarm in our monitoring environment.

Thanks Cole Libby PSINet

On Fri, 03 Jan 1997 15:03:42 -0500, dvv@sprint.net (Dima Volodin) wrote: +- |Hey, anybody from PSI here? c.root-servers.net is out of its mind, so approx |1/9 of _all_ valid DNS requests on the Internet end up with NXDOMAIN!!! | | |Dima |P.S. |Yes, I did send a message to psinet-domain-admin@PSI.COM a couple of hours ag -o. +-

Well, it's a good question :-) Anyway, we are unlikely to change this stuff until it gets annoying for ousrselves, sorry. On the other note - MHO is it was a Bad Idea to put these checks into the resolver library. No objections towards having it as an option in the code for primary zones in name servers, though. Dima Bradley Dunn writes:

Hi Dima,

Since you are from Sprint and we're talking about DNS... When does Sprint plan to fix the slashes, "/", in the names for your router interfaces? Newer resolver libraries refuse to return hostnames with invalid characters.

This obviously isn't a critical issue, but it is annoying when none of the Sprint hops in a traceroute resolve to a name.

Thanks.

-BD

On Fri, 3 Jan 1997, Dima Volodin wrote:

[stuff about c.root-servers.net being broken]

Paul A Vixie writes:

...

On the other note - MHO is it was a Bad Idea to put these checks into the resolver library. No objections towards having it as an option in the code for primary zones in name servers, though.

We debated this for a long while. It turns out that a lot of applications don't check the results of the names they get back from gethostbyaddr(), and that the architecturally pure solution would have meant letting these older applications, and their users, burn. I wasn't willing to do that. There was a CERT advisory about sendmail's queue files and PTR RRs that included \n characters, but there was no CERT advisory about the various applications who expand DNS names on shell command lines. Yes, the authors of those scripts should be shot. (Especially whoever wrote Vixie Cron.) But something would have to be done about Java as well. And who knew what else? It was not worth skewering the universe to maintain the purity of the design. So, we put the checking in at several levels.

Great. The joke is - all the old code I know worked well with the status quo ante. (It might have been a conscious decision not to know any code that wouldn't work, but it's a slightly different matter). So do I understand rightly, that there are some criteria for incorporating some bugs into the Internet (semi-)standards? Like, Vixie Cron scores here, avg's db - doesn't? Sendmail scores, Apple's resolver library (the earlier versions, at least) not? (these are rhetorical quesions, anyway) As of Java, the resolver part of its API is done with all the Sun's cluefulness (if any) about DNS, so I wonder why you started taking its (Sun's) antics into consideration now, and not when they were trying to cross YP and DNS.

Check out draft-andrews-dns-hostnames-03.txt for more info on this subject.

Now let's get off the nanog list. Dima

Please note - my position may or may not be similar to the one of Sprint.

So what we're seeing here is Sprints refusal to follow standards simply because they are too lazy(?) to fix things.

Fix what? traceroutes that started to put dotted quads where names once were?

...

On the other note - MHO is it was a Bad Idea to put these checks into the resolver library. No objections towards having it as an option in the code for primary zones in name servers, though.

I think I'm going to have to ask you to lay down the calculator and grab the wall on this one. Sprints failure to follow specifications does't mean that we shouldn't point them out and call them on it.

OK, I hear you, thank you very much.

Anyone's willing to give you a little leeway, I'll grant that, but face it, you've been (and are continuing to) breaking RFC and its certainly not the fault of the BIND team. They're doing their best to create something that works and from what you just said, Sprint is doing their best to tell them 'go to hell, we don't care about the rest of the internet'. This smacks of a Sean Doran'ism where Sprint is an almighty god figure and nobody else matters.

We do care about providing the best service possible to our customers (which includes the best possible interaction with all the other Internet). The naming scheme for the interfaces is a part of our internal automatisation, and we are not changing our internal automatisation if we think it works for our purpose of providing the best possible service. A couple of words about the bind team: 1) I greatly appreciate their effort as it's one of the canonical blocks of the Internet software, and we use their product (not without our own patches, of course) very extensively; 2) I wish the design of the canonical blocks of the Internet software was steered more by the pedantical adherence to the RFCs, and less by the desire to patch bugs in other software - canonical or otherwise. And, of course, please accept my sincerest apologies to those, whose day is ruined every time they see dotted quads instead of those funny sl-foo-bar/baz interface names.

[-] Brett L. Hawn (blh @ nol dot net) [-]

Now shall we move to some other list, please? Dima