On Thu, Nov 9, 2023 at 4:28 PM George Michaelson wrote:
> I think we're conflating how you learn what endpoint to send NOTIFY
> to, with the protocol extensions or changes to make it legal/normal to
> do NOTIFY for this purpose.
Agreed.
>
> I don't personally think the whole "but how do I kno
I think we're conflating how you learn what endpoint to send NOTIFY
to, with the protocol extensions or changes to make it legal/normal to
do NOTIFY for this purpose.
I don't personally think the whole "but how do I know where to do it"
is as important as some of you seem to think it is. But, havi
On 11/9/23 11:45, Jaap Akkerhuis wrote:
> Therefore you need to know what endpoint of the registry you need to
> send the NOTIFY to. This would just be a service listening for NOTIFYs
> to re-initiate the scanning, but it's not a name server at all. Setting
> this endpoint in the TLD z
Named at least will forward UPDATE to the primary servers. It’s off by default
because it hides the source address and UPDATE may
be restricted by IP address but it works with both TSIG and SIG(0). This is
standards defined behaviour. TSIG was designed to
support this. SIG(0) requires a bit
> On 9 Nov 2023, at 13:17, John R Levine wrote:
>
> On Thu, 9 Nov 2023, Joe Abley wrote:
>>> If we can get the registrars and registries to go for it, registry
>>> forwarding is fine with me, but I don't think it would be a good idea to
>>> specify it unless we are confident that people are wil
> On 9 Nov 2023, at 22:11, John R Levine wrote:
>
> On Thu, 9 Nov 2023, Joe Abley wrote:
>>> Apropos Joe's message, the child could hypothetically try and send the
>>> NOTIFTY to the parent SOA, e.g. a.gtld-servers.net for .com or .net. But
>>> those are clouds of anycast servers and even if
I had thought about this several years ago (ICANN-59, Johannesburg,
June 2017). I was (still am) part of the DNSSEC & Security Workshop
planning committee - and live close by. Thought about an RFP, trip to
IETF? etc..
My thought was for the DNS operator to signal the Parent at a well known
loc
On Thu, 9 Nov 2023, Joe Abley wrote:
If we can get the registrars and registries to go for it, registry forwarding
is fine with me, but I don't think it would be a good idea to specify it unless
we are confident that people are willing to do it.
To be honest I have my doubts that any of this
Hi Libor,
On 11/9/23 12:12, libor.peltan wrote:
i think this issue shall be considered in two split cases:
a) when the *registry* is to be notified. [...]
b) when the *registrar* is to be notified. [...]
The sender of the NOTIFY does not know whether, for this particular parent, the
registr
On 9 Nov 2023, at 12:12, John R Levine wrote:
> On Thu, 9 Nov 2023, Joe Abley wrote:
>> I don't agree that it's impossible to use an anycast target for this, any
>> more than it's impossible to distribute any service using anycast.
>
> I don't think it's impossible either, but it's swatting a
Hi,
i think this issue shall be considered in two split cases:
a) when the *registry* is to be notified. I think this can be achieved
easily, the registry only creates a single target for child notifies.
I'm not sure if current specs allow to do it safely (so that that target
is separated eno
On Thu, 9 Nov 2023, Joe Abley wrote:
Apropos Joe's message, the child could hypothetically try and send the NOTIFTY
to the parent SOA, e.g. a.gtld-servers.net for .com or .net. But those are
clouds of anycast servers and even if you can get that to work, they belong to
the registry while the
Michael Bauland writes:
> Therefore you need to know what endpoint of the registry you need to
> send the NOTIFY to. This would just be a service listening for NOTIFYs
> to re-initiate the scanning, but it's not a name server at all. Setting
> this endpoint in the TLD zone's SOA record as
On 9 Nov 2023, at 11:13, John R Levine wrote:
> On Wed, 8 Nov 2023, Brian Dickson wrote:
>> The target for a NOTIFY would necessarily be found in the SOA record of the
>> registrant's zone, not the parent's zone. I think that's where the
>> confusion has arisen.
>
> There's definitely confusion
Hi all,
I agree with John here.
Am 09.11.2023 um 11:11 schrieb John R Levine:
On Wed, 8 Nov 2023, Brian Dickson wrote:
The target for a NOTIFY would necessarily be found in the SOA record
of the
registrant's zone, not the parent's zone. I think that's where the
confusion has arisen.
There's
On Wed, 8 Nov 2023, Brian Dickson wrote:
The target for a NOTIFY would necessarily be found in the SOA record of the
registrant's zone, not the parent's zone. I think that's where the
confusion has arisen.
There's definitely confusion here but I don't think it's mine.
The child (registrant) pu
I think what we have here is (as Daffy Duck famously put it) "pronoun
trouble".
The target for a NOTIFY would necessarily be found in the SOA record of the
registrant's zone, not the parent's zone. I think that's where the
confusion has arisen.
The SOA record would need to be initially configured
On Wed, 8 Nov 2023, Joe Abley wrote:
I think the idea is that these two existing and well-implemented mechanisms
should be considered first to see if they fit before anybody goes to the
trouble of inventing new ones.
The most likely use case for this stuff is for a domain registrant to
updat
On 8 Nov 2023, at 19:39, John R Levine wrote:
>
>>
>>
>>> It appears that Paul Vixie said:
-=-=-=-=-=-
None of the above. Do what RFC 2136 does to send updates to the primary
authority, or do what RFC 1996
does to send notifications to all listed authorities. Any new s
It appears that Paul Vixie said:
-=-=-=-=-=-
None of the above. Do what RFC 2136 does to send updates to the primary
authority, or do what RFC 1996
does to send notifications to all listed authorities. Any new signaling is
effectively a way to go out
of band. The system is complete as it i
On 8 Nov 2023, at 18:50, John Levine wrote:
> It appears that Paul Vixie said:
>> -=-=-=-=-=-
>> None of the above. Do what RFC 2136 does to send updates to the primary
>> authority, or do what RFC 1996
>> does to send notifications to all listed authorities. Any new signaling is
>> effectiv
It appears that Paul Vixie said:
>-=-=-=-=-=-
>None of the above. Do what RFC 2136 does to send updates to the primary
>authority, or do what RFC 1996
>does to send notifications to all listed authorities. Any new signaling is
>effectively a way to go out
>of band. The system is complete as it
None of the above. Do what RFC 2136 does to send updates to the primary
authority, or do what RFC 1996 does to send notifications to all listed
authorities. Any new signaling is effectively a way to go out of band. The
system is complete as it is.
p vixie
On Nov 8, 2023 12:06, Peter Thomas
Dear DNSOP,
As laid out at the DNSOP session on Tuesday,
draft-ietf-dnsop-generalized-notify (and also
draft-johani-dnsop-delegation-mgmt-via-ddns) require a method for locating the
parent-side endpoint (target) where the child DNS operator can send a NOTIFY
for DS update (or other kind of si
24 matches
Mail list logo
