[dns-operations] policy to prevent glue for "bogus" IP addresses

Paul Hoffman phoffman at proper.com
Wed Sep 16 15:11:53 UTC 2015


Going back to the message that started this thread:


On 10 Sep 2015, at 22:41, Paul Vixie wrote:

> Warren Kumari wrote:
>>
>>
>>
>>
>> So, I'm not seeing any issue here. Someone put in an NS to a non
>> active TLD - ain't nothing the .dev registry can or should do... I
>> could reach out the Whois in the original domain letting them know
>> that their domain is busted, but they probably already knew that ...
>
> i *think* there's cause for policy here.
>
> as in, an icann accredited registrar should be required, as of the 
> next
> revision to that agreement, to remove NS RR's that point at known
> non-working addresses such as 127.0.53.53.

If you want people to work on that topic, you need to define 
"non-working addresses". Your example, 127.0.53.53 is a working address 
on my host, and that's the whole purpose of the controlled interruption.

> that may be something to bring up in the context of your ICANN SSAC
> participation.
>
> i know i don't like being fooled into sending queries to
> behind-my-firewall addresses.

If an address is working behind your firewall, then it not a 
"non-working address".

If you meant "addresses in private address space" instead of 
"non-working address", then there is still the question of why bother 
having a prohibition. You see this as "being fooled", while the 
registered owner sees it as "directing traffic to the right place on my 
network". Why should your desires trump the owner's? What are the 
security or stability issues that SSAC should look at?

If you meant "addresses on the loopback interface" instead of 
"non-working address", then there is still the question of why bother 
having a prohibition. You see this as "being fooled", while the 
registered owner sees it as "directing traffic to my own host". Why 
should your desires trump the owner's? What are the security or 
stability issues that SSAC should look at?

--Paul Hoffman



More information about the dns-operations mailing list