[DNSOP] RFC 8145 on Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)

2017-04-11 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. RFC 8145 Title: Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) Author: D. Wessels, W. Kumari, P. Hoffman Status: Standards Track

Re: [DNSOP] Fwd: New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-01.txt

2017-04-11 Thread Matthew Pounsett
On 11 April 2017 at 15:27, Carl Clements wrote: > > There is one detail that I feel is not explicit enough in 6781 that is > extremely relevant during a DNSSEC operator migration. It is assumed in > this document that DNSKEY_*_A and DNSKEY_*_B use the same signature >

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Evan Hunt
On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote: > And in order to accommodate them, we upgrade the DNS server > infrastructure across the Internet? Them, and web browser implementers who just don't want to use SRV. We did the best we could to ensure it can be deployed gradually,

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Florian Weimer
On 04/11/2017 10:16 PM, Evan Hunt wrote: On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote: I don't see how you can detect loops without DNS protocol changes. The query that comes back will look like a completely fresh query. We can put a limit on the number of hops that are

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Evan Hunt
On Tue, Apr 11, 2017 at 10:21:13PM +0200, Florian Weimer wrote: > But what happens when the target server also performs cache filling at > the same time? If two servers end up being unable to populate their address records because they're depending on each other for answers, then you end up with

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Florian Weimer
On 04/11/2017 10:15 PM, Tony Finch wrote: On 11 Apr 2017, at 20:39, Florian Weimer wrote: On 04/11/2017 09:15 PM, Tony Finch wrote: That doesn't work if the web server is at 3rd party provider A but you want provider B's mail service not provider A's. I don't

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Evan Hunt
On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote: > I don't see how you can detect loops without DNS protocol changes. The > query that comes back will look like a completely fresh query. We can put a limit on the number of hops that are followed in populating the A and

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Florian Weimer
On 04/11/2017 09:15 PM, Tony Finch wrote: On 11 Apr 2017, at 20:09, Florian Weimer wrote: On 04/11/2017 08:42 PM, Tony Finch wrote: If you have a subdomain that needs to be a mail domain and a web site, you need an MX pointing at your mail server and address records

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Florian Weimer
On 04/10/2017 12:04 PM, Peter van Dijk wrote: Section 3 is currently written in such a way that a recursive DNS lookup must be performed at the authoritative server side. I don't think it is necessary to require that. A recursive DNS lookup of the target is just one way to implement this.

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Tony Finch
> On 11 Apr 2017, at 20:09, Florian Weimer wrote: > >> On 04/11/2017 08:42 PM, Tony Finch wrote: >> >> If you have a subdomain that needs to be a mail domain and a web site, you >> need an MX pointing at your mail server and address records pointing at >> your web server.

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Florian Weimer
On 04/11/2017 08:42 PM, Tony Finch wrote: Paul Wouters wrote: Can you give me an example of deploying ANAME outside the zone APEX that is not solved by allowing a CNAME to point to a CNAME (which most code I think already allows anyway)

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Florian Weimer
On 04/11/2017 05:45 PM, Tony Finch wrote: Florian Weimer wrote: I think the introduction should discuss why it is not possible to push the CNAME to the parent zone, replacing the entire zone with an alias. You can't replace an entire zone with a CNAME if it has

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Tony Finch
Paul Wouters wrote: > > Can you give me an example of deploying ANAME outside the zone APEX that > is not solved by allowing a CNAME to point to a CNAME (which most code I > think already allows anyway) https://www.ietf.org/mail-archive/web/dnsop/current/msg19909.html If you

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Paul Wouters
On Tue, 11 Apr 2017, Tony Finch wrote: ANAME records are not just for zone apexes. There are lots of other cases where address records need a different alias target from MX records, or NAPTR records, etc. Can you give me an example of deploying ANAME outside the zone APEX that is not solved

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Tony Finch
Evan Hunt wrote: > > Expansion of ANAME on the authoritative end is a workaround for the > fact that we can't go back in time and put ANAME support into all > the resolvers. On the authoritative side I think server behaviour should be partitioned into primary and secondary:

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Tony Finch
Florian Weimer wrote: > > I think the introduction should discuss why it is not possible to push the > CNAME to the parent zone, replacing the entire zone with an alias. You can't replace an entire zone with a CNAME if it has subdomains. ANAME records are not just for zone

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

2017-04-11 Thread Peter van Dijk
Hello Jan, On 10 Apr 2017, at 16:16, Jan Včelák wrote: > On Fri, Apr 7, 2017 at 8:11 PM, Evan Hunt wrote: >> Here's the new ANAME draft I mentioned last week. > > Besides that, The Security Section should warn DNS operators that > ANAME may be misused to leak data from any internal networks the