oddity with trubuiltpambula.com.au

[Mark Andrews]

> On 19 Apr 2020, at 20:52, Karl Auer <kauer at biplane.com.au> wrote:
> 
> In the "Nameservers" section of the DNS management interface at a
> hosting provider (webcity.com.au), we see three nameservers for the
> above domain:
> 
> ns1.webcity.com.au (203.17.36.33)
> ns2.webcity.com.au (203.17.36.4)
> ns3.webcity.com.au (116.0.23.249)
> 
> However, when we query the DNS for the nameservers for this domain, we
> get different answers:
> 
> kauer at kt:~$ dig +short trubuiltpambula.com.au ns
> ns1.instanthosting.com.au.
> ns2.instanthosting.com.au.
> 
> The two instanthosting nameservers returned have the same IP addresses
> as ns1.webcity.com.au and ns2.webcity.com.au. And for completeness we
> checked and there is also an instanthosting A record pointing to the
> same IP as ns3.webcity.com.au:
> 
> kauer at kt:~$ dig +short ns3.instanthosting.com.au
> 116.0.23.249
> 
> We also get the two instanthosting nameserver names when we query any
> of those webcity nameservers directly. For example:
> 
> kauer at kt:~$ dig +short trubuiltpambula.com.au ns @ns1.webcity.com.au
> ns1.instanthosting.com.au.
> ns2.instanthosting.com.au.
> 
> A trace shows an additional lookup occurring between the website
> nameservers and the instanthosting nameservers being returned.
> 
> kauer at kt:~$ dig +trace trubuiltpambula.com.au ns
> [...]
> trubuiltpambula.com.au. 900 IN NS ns1.webcity.com.au.
> trubuiltpambula.com.au. 900 IN NS ns2.webcity.com.au.
> trubuiltpambula.com.au. 900 IN NS ns3.webcity.com.au.
> [...]
> ;; Received 660 bytes from 65.22.197.1#53(r.au) in 51 ms
> [...]
> trubuiltpambula.com.au. 43200 IN NS ns2.instanthosting.com.au.
> trubuiltpambula.com.au. 43200 IN NS ns1.instanthosting.com.au.
> ;; Received 102 bytes from 203.17.36.4#53(ns2.webcity.com.au) in 30
> ms
> 
> Is there a good explanation for what's happening?

This is the administrators for com.au and trubuiltpambula.com.au both not
following the requirements of RFC1034 to keep the NS and glue records at
the delegation consistent.

"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."

Note there isn’t a “additional lookup occurring” because what you are seeing
is a referral and a answer.  The DNS in loosely coherent and differences like
this are expected to occur WHILE DELEGATIONS ARE BEING UPDATED.  They are not
expected to be permanent and sometimes mismatches like this can cause DNS
resolution failures.

> Yours mystifiedly, K.
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at biplane.com.au)
> http://www.biplane.com.au/kauer
> http://twitter.com/kauer389
> 
> GPG fingerprint: 2561 E9EC D868 E73C 8AF1 49CF EE50 4B1D CCA1 5170
> Old fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org