Re: [dns-operations] .com delegation responses when glue addresses don't fit

[Matt Nordhoff]

On Wed, Aug 19, 2020 at 5:49 PM Mukund Sivaraman  wrote:
> We notice the following response from .com's namesevers:
>
> [muks@mx ~]$ dig +nord +dnssec +bufsize=512 @2001:502:1ca1::30 infoblox.com
>
> ; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord +dnssec +bufsize=512 
> @2001:502:1ca1::30 infoblox.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15448
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;infoblox.com.  IN  A
>
> ;; AUTHORITY SECTION:
> infoblox.com.   172800  IN  NS  ns1.infoblox.com.
> infoblox.com.   172800  IN  NS  ns2.infoblox.com.
> infoblox.com.   172800  IN  NS  ns3.infoblox.com.
> infoblox.com.   172800  IN  NS  ns4.infoblox.com.
> infoblox.com.   172800  IN  NS  ns5.infoblox.com.
> infoblox.com.   172800  IN  NS  ns6.infoblox.com.
> infoblox.com.   86400   IN  DS  33613 5 2 
> 339462CBAEB1773800EA8B688D2CA048FCAB0EB2933A97AEE2B86A9A 212F37C5
> infoblox.com.   86400   IN  DS  33613 5 1 
> 629C2D6C060E2133CD0F4470F3ECC8834DA4FAD6
> infoblox.com.   86400   IN  DS  49879 5 2 
> 605656DB7C9DFE4D8A453C350B3DA63039A78878DA089AD4247AB9A0 D3B43998
> infoblox.com.   86400   IN  DS  49879 5 1 
> C1DB78AD9A8928CB15A7E0CE9E4468D433F5C638
> infoblox.com.   86400   IN  RRSIG   DS 8 2 86400 20200823050241 
> 20200816035241 24966 com. 
> 0s/TnWuxLdVzCQqY0tVauNXeCpirT5rYacvEpxaQfTxCjP2XfZkqHy4A 
> SNoGyYWGZQdxTa7zXVgrKuWOoKZ2CKxC/kd++VnEJKoFw3llOoq56Wz+ 
> lq65BS7E6/ZlE4Qgce8rhbBQVkE6Sk1YXkuxDbwoPYfvkHlfWaboeiNO 
> 6y731Xcrq3vjqdG6YZCHyH64SSnVFypUiRN26H2HPsYsSg==
>
> ;; Query time: 19 msec
> ;; SERVER: 2001:502:1ca1::30#53(2001:502:1ca1::30)
> ;; WHEN: Wed Aug 19 17:30:29 GMT 2020
> ;; MSG SIZE  rcvd: 512
>
> [muks@mx ~]$
>
>
> Glue address records are required in this delegation response, but none
> are returned. TC=1 is not set. This causes problems with some resolvers.
>
> Can someone at Verisign please check correctness of this response, and
> set TC=1 for such responses?
>
> It appears to be the problem statement of:
> https://tools.ietf.org/html/draft-andrews-dnsop-glue-is-not-optional-01
>
> Mukund

There was a previous thread about this issue:



(The domain mentioned in that post is no longer problematic with
typical EDNS buffer sizes; you have to try 700 bytes or so.)

Verisign didn't respond at the time, unfortunately. IIRC, someone from
Verisign might have commented on
draft-andrews-dnsop-glue-is-not-optional on the dnsop list. I'd have
to check.

If someone has a contact with them, that might be better.

TLDs operated by other organizations were also affected to a lesser
extent -- I don't know of any affected domains in the wild, but it was
possible to reproduce the behavior on some of their servers. (I assume
they deploy multiple nameserver implementations.)

Of course, the whole point of DNS resilience is that every server
should work well, so it would still be good if everyone updated their
nameservers, and the draft was standardized.
-- 
Matt Nordhoff

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone

[Warren Kumari]

This seems to have died down, so I figured I'd ask if you'd managed to
pull anything like consensus out of it?

I intentionally didn't comment on the proposal, because, in my view
it's none of my business -- this is a purely operational change. The
IANA is responsible for making sure that lookups for things in .ARPA
resolve correctly; if decoupling it from the current architecture and
serving it using e.g a lightly toasted eggplant results in something
easier/better/stronger/faster, that's entirely the IANA's call.

It's nice to publish the plans and ask if it's going to break
anything/if anyone sees any issues (the root and arpa are somewhat
unusual), but as long as the queries still get answered correctly, how
you do so should be entirely your business.

The IANA is competent enough that if you say this will make things
better, I have no reason to doubt it.

W

On Fri, Aug 14, 2020 at 5:19 PM Kim Davies  wrote:
>
> Hi Paul,
>
> Quoting Paul Wouters on Wednesday August 12, 2020:
> >
> > > My take is this is a high-level expression of an operational change
> > > that is notable, but the details that would underly its implementation
> > > are not. Of course detailed plans are needed by the operator and other
> > > directly involved parties, as is the case of any other zone, but such
> > > ephemeral details are probably not best suited for RFCs.
> >
> > I am confused as to what would happen. Either, the root zone operators
> > will drop the .arpa zone, or they will keep serving it under a new
> > agreement.
>
> It is worth noting that basically the entire publication and distribution of
> the arpa zone is not contracted or otherwise covered by any agreements:
>
> * The RZMA, where ICANN contracts Verisign to produce and disseminate the
>   root zone to the RSOs, has no mention of .arpa;
>
> * Agreements that exist right now for individual RSOs don't mention .arpa
>   ;
>
> * RFC 2870, while superseded, for a long time stood stating root servers
>   "MUST NOT provide secondary service for any zones other than the root
>   and root-servers.net zones"
>
> > If they keep servigin it, either they will use the same
> > nameservers as for the root, or they will use different nameservers. If
> > they use the same nameservers, then in practise nothing will change except
> > some paperwork and people will still not want the new fancy RRTYPEs in
> > the .arpa zone. If they will use different servers, why can't they do
> > that right now?
>
> Changing the hostnames of the nameservers appears to be a precursor to any
> other kind of reconfiguration. It seems certain that .arpa can't have any
> meaningfully differentiated service so long as it is using
> {a-i,k-m}.root-servers.net as its NS-set.
>
> But that doesn't mean the end goal is necessarily full separation!
>
> The only concrete outcome proposed in this document is those hostname
> changes, and there is text that notes fuller separation would comprise
> changes in other areas as well. I think the need to progress down those
> paths, and the pace required, will depend on a number of factors such
> as whether there are new demands for the zone and whether the current
> parties are willing to continue their roles. Just as for any other zone
> operator, changes in the operational environment and evolving demands
> for the zone will inform future planning.
>
> > I am concerned that de-coupling .arpa might lead to the zone being
> > underserved. Or that IETF needs to start budgeting for running this
> > zone in the future itself. That might lead to instability as we
> > currently don't even have enough money to pay salaries due to a
> > pandemic and are temporarilly charging for things that we normally
> > do for free (online participation).
> > So from a risk management point of view, I see no reason for the
> > IETF to make a change, unless we can guarantee some longterm plan
> > for financing running the .arpa domain.
>
> Because of the lack of contracts or agreements noted above, I don't
> think there are any fundamental guarantees of service today and
> presumably the current operators could withdraw service at their
> discretion. Leaving the current configuration unmodified provides no
> certainty of future success.
>
> Identifying the proper operational expectations, and putting in place
> any necessary agreements around that, I think is a component of maturing
> the approach. Given running this domain is part of the IANA functions,
> my assumption is any additional costs borne in operating it would likely
> be borne as part of how the IANA functions are funded. This would mean
> there would be public review and engagement process associated with
> budget development on an annual basis.
>
> kim
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't 

[dns-operations] New OARC Chat Platform

[Matthew Pounsett]

Hello everyone.

DNS OARC is pleased to announce that our new community chat server is open for 
access, augmenting the mailing lists we operate.

For many years, OARC has been operating a Jabber service which has been 
available to OARC Members.  We are replacing that service with a more modern 
chat platform using Mattermost.  OARC’s chat service is available for open 
signup at .

Anyone wishing to sign up and use the platform for discussion of the DNS is 
welcome to do so.  Please be reminded that all use of OARC services is subject 
to OARC’s Code of Conduct Policy, available at 
.

Mattermost is open source software, and has open source clients available for 
all major desktop and mobile platforms.  Information on Mattermost client 
software is available at .

Mattermost makes a number of Teams available on a chat server.  In OARC’s case, 
we have the Members and Community teams available for use.  Anyone in the DNS 
community is welcome to join our Community team and use it for discussion of 
the DNS.

The Members team is open to all OARC Member and Supporter contacts.  
Non-members who would like access to that team are welcome to contact 
ad...@dns-oarc.net for information about how to become a member.

Users of the chat service are welcome to create any public or private channels 
they find useful for discussing DNS community issues, on either the Community 
or Members teams.  OARC will be monitoring team creation and activity levels in 
order to watch for abuse and do basic house keeping, but otherwise have no 
plans to monitor channel content.  If participants witness any behaviour they 
feel is in violation of OARC’s code of conduct, we ask that it be brought to 
our attention.

If anyone has any questions about the chat service, please feel free to email 
us at ad...@dns-oarc.net, or find us on Mattermost.  We hope everyone finds 
this service useful for communicating with the rest of the DNS community.

Matt Pounsett
DNS-OARC Systems Engineering





signature.asc
Description: Message signed with OpenPGP
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations