[dns-operations] Registrar for .net and .com fails to accept an NS in .edu

[John W.O'Brien]

On 2018/12/04 08:39, Robert Edmonds wrote:
> John W.O'Brien wrote:
>> Hi Duane,
>>
>> Thank you for chiming in on this. This information is convergent with
>> what I've been learning via off-list responses and from tech support
>> contacts at various organizations.
>>
>> A thing that is still causing me some grinding of gears---and this feels
>> like I may be wandering into unknowing-n00b territory---is the use of
>> the term "glue records" in this context. This is a Verisign business
>> logic-based process step, not a DNS protocol-based one. Right?
>>
>> I have succeeded in delegating a .org name to a name server in each of
>> the .edu and .net domains, and a .net name to a .org NS, and a .com name
>> to a .us NS, and none of the receiving servers are registered. What then
>> is the purpose of the consistency checks among COM, NET, and EDU from
>> Verisign's perspective? Is there any possibility of relaxing or removing
>> them? What harm is prevented that names and name servers in other TLDs
>> remain susceptible to?
> 
> .com, .net, and .edu appear to share the exact same set of nameserver IP
> addresses (e.g., a.gtld-servers.net = a.edu-servers.net = 192.5.6.30).
> In theory, a recursive resolver could notice that e.g. 192.5.6.30 is
> authoritative for .net and .edu, and allow it to provide glue records in
> .edu when resolving a name in .net, rather than discarding those glue
> records and independently resolving the addresses of the NSDNAMEs. In
> practice, I haven't heard of a resolver that implements this kind of
> bailiwick check and I would imagine most resolver implementations use
> name-based bailiwick checks.
> 

I see. If the resolver fails to implement an intersection of authority
check, and accepts out-of-bailiwick glue, then an evil authority could
trivially engage in cache poisoning.

While I agree that would be a serious problem, I'm not sure I see how
Verisign---or any TLD operator for that matter---could hope to mitigate
it meaningfully. If a resolver is susceptible to that attack, then it
will be susceptible at a deeper zone cut that is not controlled by a
registrar.

I enjoyed this thought experiment!

-- 
John W. O'Brien
Network Architect
Information Systems and Computing
University of Pennsylvania
obrienjw at upenn.edu 215-898-9818
OpenPGP key ID:
    0xD97D135B02EC753B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20181204/b236ff77/attachment.sig>