Of long names...

[Timothe Litt]

Mark,

Not a failure to bump serial.  I omitted some detail.

    I don't edit the SOA explicitly. The GoDaddy GUI is responsible for
bumping the
    serial , which it seems do do with a 'save'.
    I did add records incrementally, saved the zone and verified that
the serial increased each time.
    Both with dig and with their 'export zone' option.
    After adding the first long name, dig reported NXDOMAIN.  The SOA in
authority section had new serial.
    I added the shorter one.  Serial bumped.  Short one can be found
with dig.  Long can't.
    Added second long name, which had same length, but fewer labels.  Saved.
    dig reported NXDOMAIN;  authority section's SOA's serial incremented
again. 
    Still only the short one was visible.  Short one has two labels
(left of the domain), so domains with
    more than one label are accepted. 
    Both nameservers produce the same results.
    Logged-out and in to their GUI.  GUI could retrieve all three
names.  So the DB behind
    the GUI stored the long records.  But either didn't pass them to the
server, or the server
    rejected them.

The limits on name and label length date back to RFC1035; they're in
violation.
Even if they have some policy that reduces them (which I would object
to), the
GUI should reject names that violate that policy.  Not leave them in
limbo.  And I
tried some additional names that broke the 63 char label length limit,
which the GUI
correctly rejected.  So it does some level of validation.  Thus, it's
either total length or
number of labels that sends my names into limbo.  Or maybe both.  Or
maybe they apply
a dictionary and drop names that look like sentences - with no error. 
But their
engineers can sort that out.  Easier to do with the code than by experiment.

I think that's conclusive, which is why I stepped into the support
morass.  I'm tempted
to move the domain to my own servers, but I really hate to let vendors
get away with
customer-unfriendly support.  Other people don't have the same ability
to fight back.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 15-Mar-15 20:59, Mark Andrews wrote:
> In message <55062475.6030806 at acm.org>, Timothe Litt writes:
>> Thanks.  I appreciate the extra eyes.
>>
>> I'm pretty sure that GoDaddy has a problem between their WebGUI's database
>> and their servers.  The records appear in the former, but not (as you
>> saw), the latter.
>> Even though their GUI exports the zone file containing them with the
>> same zone serial number that your dig's SOA revealed.
> I would say "It looks like you failed to update the serial. Bump
> the serial and reload." if this was reported to bind-bugs.
>
> What is exported could be "to be loaded" content, rather than
> currently loaded content.  Add another record and publish the zone.
> If you get that record and not the "long name" records then you
> have proof of a problem.  You can then remove the extra record.
>
>> After some more detective work, I had a long, unsatisfactory 'webchat'
>> with GoDaddy support.  They had all sorts of reasons why they have no
>> problem and I'm, er, 'wrong'. Some would be extremely funny if told to a
>> technical audience.
>>
>> And since there's no problem, they refuse to escalate.  I've made an
>> out-of-band attempt to get the attention of their management.
>>
>> FWIW, bind is quite happy to accept these names in a domain where I run
>> my own servers.
>>
>> Timothe Litt
>> ACM Distinguished Engineer
>> --------------------------
>> This communication may not represent the ACM or my employer's views,
>> if any, on the matters discussed.
>>
>> On 15-Mar-15 19:49, Mukund Sivaraman wrote:
>>> On Sun, Mar 15, 2015 at 08:26:35AM -0400, Timothe Litt wrote:
>>>> Discussing a 'you don't handle long names' issue that I discovered with
>>>> an application's developer, I thought I'd create a test case or two
>> for him.
>>>> I did, but they don't resolve.  I might be missing something, so some
>>>> other eyes would be appreciated.
>>>>
>>>> The test domain is hosted on godaddy's DNS.  (Because, well, it's a
>> test
>>>> domain.)
>>>>
>>>> dns fingerprint (w3dt.net) claims their server is 'VeriSign ATLAS'
>> Does
>>>> anyone have experience with this server?
>>>>
>>>> The recursive servers queried are mine (bind) - I've flushed their
>>>> caches.  I've also tried several web services that run DNS lookups; the
>>>> results are consistent.  NXDOMAIN
>>> The authoritative nameservers for litts.us are returning NXDOMAIN for
>>> AAAA queries on these names:
>>>
>>> [muks at totoro ~]$ dig -t NS litts.us
>>>
>>> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> -t NS litts.us
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25029
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 5
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;litts.us.		IN	NS
>>>
>>> ;; ANSWER SECTION:
>>> litts.us.	3600	IN	NS	ns71.domaincontrol.com.
>>> litts.us.		3600	IN	NS	ns72.domaincontrol.com.
>>>
>>> ;; ADDITIONAL SECTION:
>>> NS72.domaincontrol.com.	132465	IN	A	208.109.255.46
>>> NS72.domaincontrol.com.	172484	IN	AAAA	2607:f208:302::2e
>>> ns71.domaincontrol.com.	132465	IN	A	216.69.185.46
>>> ns71.domaincontrol.com.	172484	IN	AAAA	2607:f208:206::2e
>>>
>>> ;; Query time: 83 msec
>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>> ;; WHEN: Mon Mar 16 05:13:23 IST 2015
>>> ;; MSG SIZE  rcvd: 185
>>>
>>> [muks at totoro ~]$ dig +norecurse @ns71.domaincontrol.com -t aaaa
>> oh-what-a-beautiful-morning.oh-what-a-beautiful-day.oh-what-a-wonderful-fe
>> eling.everythings-lost-in-the-hay.litts.us
>>> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> +norecurse
>> @ns71.domaincontrol.com -t aaaa
>> oh-what-a-beautiful-morning.oh-what-a-beautiful-day.oh-what-a-wonderful-fe
>> eling.everythings-lost-in-the-hay.litts.us
>>> ; (2 servers found)
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65035
>>> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>>
>> ;oh-what-a-beautiful-morning.oh-what-a-beautiful-day.oh-what-a-wonderful-f
>> eeling.everythings-lost-in-the-hay.litts.us. IN AAAA
>>> ;; AUTHORITY SECTION:
>>> litts.us.	3600	IN	SOA	ns71.domaincontrol.com.
>> dns.jomax.net. 2015031503 28800 7200 604800 3600
>>> ;; Query time: 86 msec
>>> ;; SERVER: 216.69.185.46#53(216.69.185.46)
>>> ;; WHEN: Mon Mar 16 05:14:53 IST 2015
>>> ;; MSG SIZE  rcvd: 216
>>>
>>> [muks at totoro ~]$ dig +norecurse @ns72.domaincontrol.com -t aaaa
>> oh-what-a-beautiful-morning.oh-what-a-beautiful-day.oh-what-a-wonderful-fe
>> eling.everythings-lost-in-the-hay.litts.us
>>> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> +norecurse
>> @ns72.domaincontrol.com -t aaaa
>> oh-what-a-beautiful-morning.oh-what-a-beautiful-day.oh-what-a-wonderful-fe
>> eling.everythings-lost-in-the-hay.litts.us
>>> ; (2 servers found)
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15081
>>> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>>
>> ;oh-what-a-beautiful-morning.oh-what-a-beautiful-day.oh-what-a-wonderful-f
>> eeling.everythings-lost-in-the-hay.litts.us. IN AAAA
>>> ;; AUTHORITY SECTION:
>>> litts.us.	3600	IN	SOA	ns71.domaincontrol.com.
>> dns.jomax.net. 2015031503 28800 7200 604800 3600
>>> ;; Query time: 83 msec
>>> ;; SERVER: 208.109.255.46#53(208.109.255.46)
>>> ;; WHEN: Mon Mar 16 05:15:41 IST 2015
>>> ;; MSG SIZE  rcvd: 216
>>>
>>>
>>> 		Mukund
>>
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150315/e29a25b1/attachment.bin>