Moin!
On 11 Jun 2019, at 20:40, Jonas Frey wrote:
> I do see 3 major benefits to combine/unify these:
> - "saving" IP addresses (depending of how many you run of course[1])
Should not be a problem with IPv6, and running the same function
like http on the same IP is quite different from running dif
Ian,
> I'd argue that it is not controversial at all.
> We have good BCP and the RIPE NCC delegation checks it.
> By all means wait for the RIPE NCC to respond, but I see no reason to
> change the status quo.
> This seems like a complaint about nothing of importance IMHO.
>
> Ian
Well, even if
> Because 20 years ago, we realised that this is a problem and stopped
> intermingling recursive and authoritative service. Software like the
> djb suite, nsd and unbound was written to assist in this separation.
>
> Thus, noone has bothered to revisit the docs on the subject.
>
> Part of the re
> I suggest we wait for the NCC folks to come back with the exact list of
> requirements used today and starting from those the community, since this is
> more controversial than I and others thought, should try to formulate a
> policy that is consistent with the desires and needs of the communi
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Tue, Jun 11, 2019
at 07:52:18PM +0200 Quoting Jonas Frey (j...@probe-networks.de):
> It seems to me that all documentation regarding this topic is highly
> outdated (atleast what i have found, see ISC's docs for BIND).
Because 20 years
Hi,
On Tue, Jun 11, 2019 at 08:40:05PM +0200, Jonas Frey wrote:
> > The time window might be small, but serving wrong answers was not
> > acceptable for us.
>
> ok, but in the automated world of today this small window is likely to
> be _really_ small.
Only if everything works perfectly. Espec
Gert,
>
> The time window might be small, but serving wrong answers was not
> acceptable for us.
>
>
ok, but in the automated world of today this small window is likely to
be _really_ small.
>
>
> Can you explain why it would be desirable to *have* these unified?
>
> Gert Doering
>
Hi,
On Tue, Jun 11, 2019 at 07:52:18PM +0200, Jonas Frey wrote:
> If cache poising is beeing taken care of (be it via DNSSEC or else)
> what other reasons are there to not combine both?
Well, the reason we separated these functions (like some 20 years ago)
was "provisioning of customer domains th
> Nope. There are other much more unpleasant impacts: consider cache
> poisoning.
>
> If your authoritative server also handles arbitrary recursive
> queries, I can make your name server query my DNS server which tells
> lies. Unless your server does DNSSEC validation, it will then spread
> these
> None of those organisations run authoritative servers on the same
> open recursive servers, either for direct or reverse domains.
>
>
>
> Rubens
>
>
Rubens,
neither me nor Jim Reid claimed that here, please re-read our replys:
> Run a open resolver and secure it propely
These two thi
> Em 11 de jun de 2019, à(s) 13:58:000, Jonas Frey
> escreveu:
>
>
>>> Run a open resolver and secure it propely
>> These two things are mutually exclusive. Sorry.
>>
>
> Well, then all of these (running open resolvers) must be wrong:
> - Google
> - Cloudflare
> - Quad9
> - OpenDNS
> - Yan
> On 11 Jun 2019, at 17:58, Jonas Frey wrote:
>
>>> Run a open resolver and secure it propely
>> These two things are mutually exclusive. Sorry.
>>
>
> Well, then all of these (running open resolvers) must be wrong:
> - Google
> - Cloudflare
> - Quad9
> ...
They’ve taken business decisions t
> On 11 Jun 2019, at 17:28, Jonas Frey wrote:
>
> As previously noted most (if not all) ccTLD registrys do not block when
> a open recursor is found. (C/N/O: Verisign pass, EU EURID: pass, DE DE-
> NIC: pass with warn).
> Now that these ccTLDs deal with *alot* more nameservers than RIPE
> (prob
> > Run a open resolver and secure it propely
> These two things are mutually exclusive. Sorry.
>
Well, then all of these (running open resolvers) must be wrong:
- Google
- Cloudflare
- Quad9
- OpenDNS
- Yandex
- Comodo
- Norton
- Clean Browsing
- ...
Anyway, isnt this the wrong discussion? Th
> On 11 Jun 2019, at 17:28, Jonas Frey wrote:
>
> Run a open resolver and secure it propely
These two things are mutually exclusive. Sorry.
signature.asc
Description: Message signed with OpenPGP
Hello all,
as for this topic, i have started the discussion on the members-discuss
list.
So far it seems there are various opinions about this topic. From the
replys i have received it seems these are:
- Dont run a open resolver, let RIPE block
- Dont run a open resolver, let RIPE warn
- Run a
On 11/06/2019 13:00, Tony Finch wrote:
Hi Tony,
>> The RIPE NCC recently announced at RIPE 78 that they now support RFC 8078 for
>> reverse DNS:
>>
>> https://ripe78.ripe.net/presentations/138-138-RIPE78_DNS_Update.pdf
>
> Oh, this is cool! Is there any more information anywhere? I couldn't find
Shane Kerr wrote:
>
> The RIPE NCC recently announced at RIPE 78 that they now support RFC 8078 for
> reverse DNS:
>
> https://ripe78.ripe.net/presentations/138-138-RIPE78_DNS_Update.pdf
Oh, this is cool! Is there any more information anywhere? I couldn't find
any details in the RIPE database doc
Subject: Re: [dns-wg] NCC reverse delegation criteria Date: Tue, Jun 11, 2019
at 10:52:00AM +0200 Quoting Anand Buddhdev (ana...@ripe.net):
> Good morning Måns,
>
> We will come back to you shortly with answers to your and others'
> questions in this thread.
Excellent!
--
Måns Nilsson pri
Good morning Måns,
We will come back to you shortly with answers to your and others'
questions in this thread.
Regards,
Anand Buddhdev
RIPE NCC
On 10/06/2019 09:22, Måns Nilsson wrote:
> Recently, a discussion regarding the checks performed by the NCC before
> reverse delegation is made came up
> On 10 Jun 2019, at 18.04, Shane Kerr wrote:
>
>
>
> Of course, if the goal was ADDING of DS records, then I admit that the system
> is not there. I can see the benefit of being able to add DS records to the
> parent via CDS/CDNSKEY, especially for operators trying to secure (for
> example
21 matches
Mail list logo
