www.spps-serv.ch - what is going on here?

[Kevin Darcy]

Karl Auer wrote:
> This is almost certainly a stupid question, but I can't get my head
> around it.
> It all started because our people complained that they couldn't resolve
> www.spps-serv.ch. Except that sometimes, they could.
>
> First off, here's the trace to the SOA for spps-serv.ch:
>
> kauer at karl:~$ dig +trace spss-serv.ch
> [...]
> spss-serv.ch.           43200   IN      NS      ns1.spss-serv.ch.
> spss-serv.ch.           43200   IN      NS      ns2.spss-serv.ch.
> ;; Received 98 bytes from 194.146.106.10#53(ch1.dnsnode.net) in 2100 ms
>
> spss-serv.ch.           3600    IN      SOA
> spss-services.spss-servers.ch. hostmaster.spss-servers.ch. 21 900 600
> 86400 3600
>
> When looked up normally, these nameservers don't exist:
> kauer at karl:~$ dig +short ns1.spss-serv.ch. 
> kauer at karl:~$ dig +short ns2.spss-serv.ch. 
>
> But if you ask them, by name, about themselves, they can be resolved and
> can answer!
> kauer at karl:~$ dig +short ns1.spss-serv.ch. @ns1.spss-serv.ch.
> 212.215.3.70
> kauer at karl:~$ dig +short ns2.spss-serv.ch. @ns1.spss-serv.ch.
> 212.215.3.74
>
> Both of them have data for www.spss-serv.ch:
> kauer at karl:~$ dig +short www.spss-serv.ch. @ns1.spss-serv.ch. 
> 212.215.3.70
> kauer at karl:~$ dig +short www.spss-serv.ch. @ns2.spss-serv.ch. 
> 212.215.3.70
>
> If you ask those nameservers to tell you the zone nameservers, though,
> you get a totally different nameserver name back:
>
> kauer at karl:~$ dig +short spss-serv.ch ns @ns1.spss-serv.ch.
> spss-services.spss-servers.ch.
> kauer at karl:~$ dig +short spss-serv.ch ns @ns2.spss-serv.ch.
> spss-services.spss-servers.ch.
>   
Well, spss-serv.ch != spss-servers.ch. The spss-servers.ch domain isn't 
even delegated.

Simply put, the apex NS record points to a non-existent name.
> And (drum roll), that nameserver name doesn't resolve:
> ; <<>> DiG 9.3.4-P1.1 <<>> spss-services.spss-servers.ch.
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 985
>
> Not even on the delegated servers:
> ; <<>> DiG 9.3.4-P1.1 <<>> spss-services.spss-servers.ch. @ns1.spss-serv.ch.
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63399
>
> So the zone is seriously confused. So am I. What I don't understand is
> why the officially delegated nameservers can be resolved when asked
> about themselves, but not when the ordinary resolvers are asked to
> resolve them. Something to do with when dig decides to go via the root?
>   
An apex NS record is considered more "trustworthy" than delegating NS 
records, so once the *bad* apex NS record is seen, it will overwrite the 
existing cache entry and inhibit iterative resolution of names in the 
zone until the cache entry times out.

The result? You can only resolve the A records in the zone with a 
"fresh" iterative query (where no bad spss-serv.ch/NS info is cached) or 
by asking the authoritative nameservers directly.

                                                                         
                     - Kevin