[Pidgin] #8145: pidgin.im DNS zone missing glue records
Pidgin
trac at pidgin.im
Fri Jan 16 12:37:12 EST 2009
#8145: pidgin.im DNS zone missing glue records
-----------------------+----------------------------------------------------
Reporter: gene_wood | Owner: lschiere
Type: defect | Status: new
Milestone: | Component: unclassified
Version: 2.5.4 | Resolution:
Keywords: |
-----------------------+----------------------------------------------------
Description changed by gene_wood:
Old description:
> Currently the DNS zone "pidgin.im" has 3 nameservers configured with the
> Isle of Man registrar :
>
> {{{
> [ewood at adm02oak ~]$ dig pidgin.im NS
>
> ; <<>> DiG 9.2.4 <<>> pidgin.im NS
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56374
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
>
> ;; QUESTION SECTION:
> ;pidgin.im. IN NS
>
> ;; ANSWER SECTION:
> pidgin.im. 148 IN NS imperial.pidgin.im.
> pidgin.im. 148 IN NS ns1.reaperworld.com.
> pidgin.im. 148 IN NS rock.pidgin.im.
>
> ;; ADDITIONAL SECTION:
> imperial.pidgin.im. 148 IN A 74.63.8.111
> ns1.reaperworld.com. 85840 IN A 208.100.2.214
> rock.pidgin.im. 148 IN A 74.63.8.88
>
> ;; Query time: 4 msec
> ;; SERVER: 10.0.4.102#53(10.0.4.102)
> ;; WHEN: Fri Jan 16 09:19:25 2009
> ;; MSG SIZE rcvd: 150
> }}}
>
> Of those 3 nameservers (imperial.pidgin.im, ns1.reaperworld.com,
> rock.pidgin.im) 2 of them are subdomains of pidgin.im and 1 is a
> subdomain of reaperworld.com.
>
> Since 2 of the nameservers are subdomains of the same domain which they
> define, they require that glue records be established with the registrar
> and served from the ".im" TLD nameservers. ( More information on what a
> glue record is :
> http://en.wikipedia.org/wiki/Domain_name_system#Circular_dependencies_and_glue_records
> )
>
> Here is the evidence of the missing blue records. Note how each response
> from the various ".im" nameservers return the NS records but no matching
> A records.
>
> {{{
> [ewood at adm02oak ~]$ dig im NS
>
> ; <<>> DiG 9.2.4 <<>> im NS
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1867
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
>
> ;; QUESTION SECTION:
> ;im. IN NS
>
> ;; ANSWER SECTION:
> im. 17957 IN NS pebbles.iom.com.
> im. 17957 IN NS hoppy.iom.com.
> im. 17957 IN NS barney.advsys.co.uk.
>
> ;; ADDITIONAL SECTION:
> pebbles.iom.com. 17957 IN A 80.168.83.242
> hoppy.iom.com. 17957 IN A 217.23.163.140
> barney.advsys.co.uk. 17957 IN A 217.23.160.50
>
> ;; Query time: 0 msec
> ;; SERVER: 10.0.4.102#53(10.0.4.102)
> ;; WHEN: Fri Jan 16 09:14:52 2009
> ;; MSG SIZE rcvd: 150
>
> [ewood at adm02oak ~]$ dig @80.168.83.242 pidgin.im NS
>
> ; <<>> DiG 9.2.4 <<>> @80.168.83.242 pidgin.im NS
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11496
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;pidgin.im. IN NS
>
> ;; AUTHORITY SECTION:
> pidgin.im. 43200 IN NS rock.pidgin.im.
> pidgin.im. 43200 IN NS imperial.pidgin.im.
> pidgin.im. 43200 IN NS ns1.reaperworld.com.
>
> ;; Query time: 161 msec
> ;; SERVER: 80.168.83.242#53(80.168.83.242)
> ;; WHEN: Fri Jan 16 09:16:11 2009
> ;; MSG SIZE rcvd: 102
>
> [ewood at adm02oak ~]$ dig @217.23.163.140 pidgin.im
>
> ; <<>> DiG 9.2.4 <<>> @217.23.163.140 pidgin.im
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37486
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;pidgin.im. IN A
>
> ;; AUTHORITY SECTION:
> pidgin.im. 43200 IN NS rock.pidgin.im.
> pidgin.im. 43200 IN NS imperial.pidgin.im.
> pidgin.im. 43200 IN NS ns1.reaperworld.com.
>
> ;; Query time: 159 msec
> ;; SERVER: 217.23.163.140#53(217.23.163.140)
> ;; WHEN: Fri Jan 16 09:14:57 2009
> ;; MSG SIZE rcvd: 102
>
> [ewood at adm02oak ~]$ dig @217.23.160.50 pidgin.im NS
>
> ; <<>> DiG 9.2.4 <<>> @217.23.160.50 pidgin.im NS
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33856
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;pidgin.im. IN NS
>
> ;; AUTHORITY SECTION:
> pidgin.im. 43200 IN NS rock.pidgin.im.
> pidgin.im. 43200 IN NS imperial.pidgin.im.
> pidgin.im. 43200 IN NS ns1.reaperworld.com.
>
> ;; Query time: 162 msec
> ;; SERVER: 217.23.160.50#53(217.23.160.50)
> ;; WHEN: Fri Jan 16 09:15:37 2009
> ;; MSG SIZE rcvd: 102
> }}}
>
> Compare this to a correctly configured zone like "google.com" note how
> the query for the google.com NS records not only returns the 4 NS records
> (ns1.google.com, ns2.google.com, ns3.goolge.com, ns4.google.com) but also
> the associated glue records :
>
> ns1.google.com. 172800 IN A 216.239.32.10
> ns2.google.com. 172800 IN A 216.239.34.10
> ns3.google.com. 172800 IN A 216.239.36.10
> ns4.google.com. 172800 IN A 216.239.38.10
>
> {{{
> [ewood at adm02oak ~]$ dig google.com NS
>
> ; <<>> DiG 9.2.4 <<>> google.com NS
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13133
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3
>
> ;; QUESTION SECTION:
> ;google.com. IN NS
>
> ;; ANSWER SECTION:
> google.com. 84730 IN NS ns2.google.com.
> google.com. 84730 IN NS ns1.google.com.
> google.com. 84730 IN NS ns4.google.com.
> google.com. 84730 IN NS ns3.google.com.
>
> ;; ADDITIONAL SECTION:
> ns2.google.com. 84730 IN A 216.239.34.10
> ns4.google.com. 84730 IN A 216.239.38.10
> ns3.google.com. 84730 IN A 216.239.36.10
>
> ;; Query time: 2 msec
> ;; SERVER: 10.0.4.102#53(10.0.4.102)
> ;; WHEN: Fri Jan 16 09:34:00 2009
> ;; MSG SIZE rcvd: 148
> }}}
>
> The result of these missing glue records for the pidgin.im domain is that
> 66% of all DNS lookups for pidgin.im will fail. Any client which looks up
> the name www.pidgin.im will 2 out of 3 times be served either
> rock.pidgin.im or imperial.pidgin.im as the authoritative nameservers for
> the pidgin.im zone at which point the client will fail because it's run
> into a circular dependency (how can it find the IP address of either of
> those pidgin.im nameservers if it has to be able to lookup the names of
> the nameservers)
>
> This means that 66% of the time users when attempting to browse to
> www.pidgin.im will fail. This misconfiguration is drastically restricting
> people's abilities to reach your site.
>
> Please take one of the following actions to resolve this problem :
>
> * create the glue records with the Isle of Man name registrar
> * remove the nameservers rock.pidgin.im and imperial.pidgin.im from the
> registrar's records for the pidgin.im zone and run exclusively on
> ns1.reaperworld.com
> * establish new names for rock.pidgin.im and imperial.pidgin.im in any
> zone other than "pidgin.im" (for example "rock.pidgin.reaperworld.com"
> and "imperial.pidgin.reaperworld.com" which map those names to the
> associated IPs (74.63.8.88 and 74.63.8.111) then update your registrar's
> records so the NS servers for the zone pidgin.im are configured as (for
> example) :
>
> ns1.reaperworld.com
> imperial.pidgin.reaperworld.com
> rock.pidgin.reaperworld.com
>
> The recommended solution is the first one of just establishing the glue
> records.
New description:
Currently the DNS zone "pidgin.im" has 3 nameservers configured with the
Isle of Man registrar :
{{{
[ewood at adm02oak ~]$ dig pidgin.im NS
; <<>> DiG 9.2.4 <<>> pidgin.im NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56374
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;pidgin.im. IN NS
;; ANSWER SECTION:
pidgin.im. 148 IN NS imperial.pidgin.im.
pidgin.im. 148 IN NS ns1.reaperworld.com.
pidgin.im. 148 IN NS rock.pidgin.im.
;; ADDITIONAL SECTION:
imperial.pidgin.im. 148 IN A 74.63.8.111
ns1.reaperworld.com. 85840 IN A 208.100.2.214
rock.pidgin.im. 148 IN A 74.63.8.88
;; Query time: 4 msec
;; SERVER: 10.0.4.102#53(10.0.4.102)
;; WHEN: Fri Jan 16 09:19:25 2009
;; MSG SIZE rcvd: 150
}}}
Of those 3 nameservers (imperial.pidgin.im, ns1.reaperworld.com,
rock.pidgin.im) 2 of them are subdomains of pidgin.im and 1 is a subdomain
of reaperworld.com.
Since 2 of the nameservers are subdomains of the same domain which they
define, they require that glue records be established with the registrar
and served from the ".im" TLD nameservers. ( More information on what a
glue record is :
http://en.wikipedia.org/wiki/Domain_name_system#Circular_dependencies_and_glue_records
)
Here is the evidence of the missing blue records. Note how each response
from the various ".im" nameservers return the NS records but no matching A
records.
{{{
[ewood at adm02oak ~]$ dig im NS
; <<>> DiG 9.2.4 <<>> im NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1867
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;im. IN NS
;; ANSWER SECTION:
im. 17957 IN NS pebbles.iom.com.
im. 17957 IN NS hoppy.iom.com.
im. 17957 IN NS barney.advsys.co.uk.
;; ADDITIONAL SECTION:
pebbles.iom.com. 17957 IN A 80.168.83.242
hoppy.iom.com. 17957 IN A 217.23.163.140
barney.advsys.co.uk. 17957 IN A 217.23.160.50
;; Query time: 0 msec
;; SERVER: 10.0.4.102#53(10.0.4.102)
;; WHEN: Fri Jan 16 09:14:52 2009
;; MSG SIZE rcvd: 150
[ewood at adm02oak ~]$ dig @80.168.83.242 pidgin.im NS
; <<>> DiG 9.2.4 <<>> @80.168.83.242 pidgin.im NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11496
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;pidgin.im. IN NS
;; AUTHORITY SECTION:
pidgin.im. 43200 IN NS rock.pidgin.im.
pidgin.im. 43200 IN NS imperial.pidgin.im.
pidgin.im. 43200 IN NS ns1.reaperworld.com.
;; Query time: 161 msec
;; SERVER: 80.168.83.242#53(80.168.83.242)
;; WHEN: Fri Jan 16 09:16:11 2009
;; MSG SIZE rcvd: 102
[ewood at adm02oak ~]$ dig @217.23.163.140 pidgin.im
; <<>> DiG 9.2.4 <<>> @217.23.163.140 pidgin.im
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37486
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;pidgin.im. IN A
;; AUTHORITY SECTION:
pidgin.im. 43200 IN NS rock.pidgin.im.
pidgin.im. 43200 IN NS imperial.pidgin.im.
pidgin.im. 43200 IN NS ns1.reaperworld.com.
;; Query time: 159 msec
;; SERVER: 217.23.163.140#53(217.23.163.140)
;; WHEN: Fri Jan 16 09:14:57 2009
;; MSG SIZE rcvd: 102
[ewood at adm02oak ~]$ dig @217.23.160.50 pidgin.im NS
; <<>> DiG 9.2.4 <<>> @217.23.160.50 pidgin.im NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33856
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;pidgin.im. IN NS
;; AUTHORITY SECTION:
pidgin.im. 43200 IN NS rock.pidgin.im.
pidgin.im. 43200 IN NS imperial.pidgin.im.
pidgin.im. 43200 IN NS ns1.reaperworld.com.
;; Query time: 162 msec
;; SERVER: 217.23.160.50#53(217.23.160.50)
;; WHEN: Fri Jan 16 09:15:37 2009
;; MSG SIZE rcvd: 102
}}}
Compare this to a correctly configured zone like "google.com" note how the
query for the google.com NS records not only returns the 4 NS records
(ns1.google.com, ns2.google.com, ns3.goolge.com, ns4.google.com) but also
the associated glue records :
{{{
ns1.google.com. 172800 IN A 216.239.32.10
ns2.google.com. 172800 IN A 216.239.34.10
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN A 216.239.38.10
}}}
{{{
[ewood at adm02oak ~]$ dig google.com NS
; <<>> DiG 9.2.4 <<>> google.com NS
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13133
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;google.com. IN NS
;; ANSWER SECTION:
google.com. 84730 IN NS ns2.google.com.
google.com. 84730 IN NS ns1.google.com.
google.com. 84730 IN NS ns4.google.com.
google.com. 84730 IN NS ns3.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 84730 IN A 216.239.34.10
ns4.google.com. 84730 IN A 216.239.38.10
ns3.google.com. 84730 IN A 216.239.36.10
;; Query time: 2 msec
;; SERVER: 10.0.4.102#53(10.0.4.102)
;; WHEN: Fri Jan 16 09:34:00 2009
;; MSG SIZE rcvd: 148
}}}
The result of these missing glue records for the pidgin.im domain is that
66% of all DNS lookups for pidgin.im will fail. Any client which looks up
the name www.pidgin.im will 2 out of 3 times be served either
rock.pidgin.im or imperial.pidgin.im as the authoritative nameservers for
the pidgin.im zone at which point the client will fail because it's run
into a circular dependency (how can it find the IP address of either of
those pidgin.im nameservers if it has to be able to lookup the names of
the nameservers)
This means that 66% of the time users when attempting to browse to
www.pidgin.im will fail. This misconfiguration is drastically restricting
people's abilities to reach your site.
Please take one of the following actions to resolve this problem :
* create the glue records with the Isle of Man name registrar[[BR]]
* remove the nameservers rock.pidgin.im and imperial.pidgin.im from the
registrar's records for the pidgin.im zone and run exclusively on
ns1.reaperworld.com[[BR]]
* establish new names for rock.pidgin.im and imperial.pidgin.im in any
zone other than "pidgin.im" (for example "rock.pidgin.reaperworld.com" and
"imperial.pidgin.reaperworld.com" which map those names to the associated
IPs (74.63.8.88 and 74.63.8.111) then update your registrar's records so
the NS servers for the zone pidgin.im are configured as (for example)
:[[BR]]
{{{
ns1.reaperworld.com
imperial.pidgin.reaperworld.com
rock.pidgin.reaperworld.com
}}}
The recommended solution is the first one of just establishing the glue
records.
--
--
Ticket URL: <http://developer.pidgin.im/ticket/8145#comment:1>
Pidgin <http://pidgin.im>
Pidgin
More information about the Tracker
mailing list