![nanog logo](/images/nanog-logo.png)
nanog mailing list archives
Re: Interesting new dns failures
From: Mark Andrews <Mark_Andrews () isc org>
Date: Mon, 21 May 2007 19:10:20 +1000 (EST)
In article <20070521081322.GA741 () nic fr> you write:
On Sun, May 20, 2007 at 09:25:37PM -0700, Roger Marquis <marquis () roble com> wrote a message of 15 lines which said:If not, have any root nameservers been hacked?To partly answer my own question, no.I cannot find the original message in my mailbox. (Not on NANOG mailing list archives.) What was the issue?The data returned by root (gtld) nameservers is not changing rapidly.Now, I understand nothing. Is there a problem with the root nameservers or with some gTLD nameservers???
There isn't a problem with the root or tld servers. There is a problem with the server for these zones. They don't speak RFC 1034, hence the error messages about garbage responses. Note the answer doesn't match the question. ; <<>> DiG 9.5.0a2 <<>> @76.183.141.203 ns6.loptran.com +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36800 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns6.loptran.com. IN A ;; ANSWER SECTION: loptran.com. 0 IN A 24.218.122.218 ;; Query time: 212 msec ;; SERVER: 76.183.141.203#53(76.183.141.203) ;; WHEN: Mon May 21 19:05:58 2007 ;; MSG SIZE rcvd: 60 There is a problem with the whole delegation process in that no one involved in the delegation seems to care that absolute garbage is being injected into the DNS. A few simple checks, like above, would have show that the servers were not RFC 1034 compliant. That the glue was not a copy of the records in the child zone. The parent *is* required by RFC 1034 to check this. RFC 1034, 4.2.2. Administrative considerations, paragraph 3. As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. These zones should be pulled. Mark
Current thread:
- Re: Interesting new dns failures, (continued)
- Re: Interesting new dns failures Per Heldal (May 24)
- Re: Interesting new dns failures Suresh Ramasubramanian (May 24)
- Re: Interesting new dns failures John LaCour (May 24)
- Re: Interesting new dns failures Suresh Ramasubramanian (May 24)
- Re: Interesting new dns failures Hank Nussbacher (May 23)
- Re: Interesting new dns failures Roger Marquis (May 22)
- Re: Interesting new dns failures David Ulevitch (May 22)
- Re: Interesting new dns failures Chris L. Morrow (May 22)
- Re: Interesting new dns failures Suresh Ramasubramanian (May 22)
- Re: Interesting new dns failures Mark Andrews (May 21)
- Re: Interesting new dns failures Gadi Evron (May 21)
- Re: Interesting new dns failures Roger Marquis (May 21)
- Re: Interesting new dns failures Valdis . Kletnieks (May 21)
- Use of portions of 44.0.0.0/8? Neal R (May 21)
- Re: Use of portions of 44.0.0.0/8? Andy Brezinsky (May 21)
- OK - functioning administration of 44.0.0.0/8 Neal R (May 21)
- Re: OK - functioning administration of 44.0.0.0/8 Harald Koch (May 21)