Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Edward Lewis]

On 5/11/23, 7:30 PM, "DNSOP on behalf of Mark Andrews"  wrote:
>
>It’s not a challenge to track what is lame.  It’s dead simple.  You just 
> have to look.  Getting
>it addressed is the challenge.

Speaking from experience (which means I'm about to launch an amplification 
attack here: taking a short message and adding in stories from the past few 
decades in this area), this is very true.  Using the analogy of observing 
symptoms, diagnosing cause, prescribing a fix, and following through, it's easy 
to tell when someone coughs - but, if the cause happens to be from a personal 
habit, very difficult to mitigate.

In following this discussion, admitting that I have no idea what "rfc8499bis" 
is (not a title, not a document file name, not a link), I ought to throw in 
this question: "Why do broken delegations (lame, unreachable address, etc.) 
matter?"  So in some sense I'm committing an IETF sin.

In my experience with lameness, the problem was rather specific.  In that era, 
a server, given a question it could not answer would refer the querier to the 
root zone - perhaps as some sort of joke initially.  The trouble was that some 
resolvers were not in on the joke (and I bet there was no technical document 
specifying what an "upwards referral" signified) but it turned out to be pretty 
easy to fix the problematic resolvers.  (It was one major, proprietary source 
who, surprisingly to many in the open source fandom, actually fixed their bug.) 
 I'm not sure my work in quantifying the amount of lameness ever mattered as 
the eradication process undertaken seemed to overcome by the fix of the 
resolvers (nevertheless, it was pretty interesting research to conduct).

(This is the central thought of this rant:)
It's true that if a registrant misconfigures their delegation or servers, their 
service will suffer.  But does this have fallout for anyone other than their 
service users?  Other than researchers who poke into this stuff (like me)?  
Does it impact the registry delegating to the registrant?

From other experience, I once dove into an incident (details I can't divulge).  
One of the things I identified was the source of the queries for a particular 
DNSSEC-related data set.  In the top-ten queries was a "labs" machine - a 
research organization was "pounding" the servers for this data set to the 
extent they were a noticeable portion of the incoming traffic.  At times, 
research is not measuring traffic but becoming the traffic.

And from another experience, I once had to deal with a customer who had a zone 
delegated to the servers that we operated but neglected to tell us.  (The very 
picture of lameness, completely unrelated to my earlier lameness 
quantification.)  Our monitors did not know the incoming queries were headed 
for one of our current customer's zone as we didn't know the zone was theirs.  
We thought it was simply DDoS-related traffic.  A factor here is that the 
operations I am talking about were not a TLD of any kind (hence the last label 
was not tell-tale).

And yet another experience, I've dealt with situations where a major change was 
being proposed but those that needed to play along had absolutely no 
relationship with us.  The Internet encourages people to plug in and play 
without being subject to remote monitoring.  At times that is very good.  At 
times that is very frustrating.  What I learned from that was no one can set 
expectations on what someone else will do on the Internet.  One can't expect 
protocol conformance from an entity with which you have no relationship, but 
you need to be prepared to deal with whatever comes (a take on "liberal accept, 
conservative send" - that adage attributed to Jon Postel).

It's fine to quantify situations.  It's fine to launch campaigns to improve the 
"health&safety" of the Internet and fine to measure the impact of the 
campaigns.  But you can never expect to see "success".  This is really 
frustrating when changes (including clarifications) are sorely needed to 
improve the state of operations across the global public Internet.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John R Levine]

Yeah, that's a better way to put it. But the main point still stands,
that it would be a signficant operational change to insist that all
delegated NS be active when delegated, and even moreso to insist that
they continue to be active. ...



Well, OK, you do that, half the emails bounce, half of what's delivered is 
reported as spam, and the third half are ignored.  Now what?


In practice it isn’t quite as bad as that.  Require registrars to refuse
renewals until the issues are addressed.


Please see "signficant operational change" above.

My feeling is that if it's not important enough for *you* to have your DNS 
working, it's not important for *me* either.  I'm happy to help people who 
are having trouble fixing problems, but not to waste time on people who 
don't care.


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Rubens Kuhl]

> Em 6 de mai. de 2023, à(s) 12:20, John Levine  escreveu:
> 
> It appears that Joe Abley   said:
>> Pre-delegation checks add friction to the domain registration process. They 
>> further complicate the commuications between different actors in the 
>> commercial graph
>> (registrars, registries, resellers, DNS operators, hosting companies) and 
>> introduce delay and manual intervention into what might otherwise be a 
>> fairly automated
>> or at least automatable process. ...
> 
> Thirty years ago, when you did domain registrations by e-mail, the
> registry which was then called Network Solutions did indeed check that
> your name servers were active before delegating the domain. It was not
> an accident that they stopped doing so, and it seems vanishingly
> unlikely that any gTLD registry would do so now, regardless of
> what people here might think.

Actually, there is one gTLD that does that: .rio. A domain can be registered 
without working DNS servers, but it won’t be delegated until DNS servers answer 
with authority for that domain. 

.rio also checks DNS authority when a domain updates its delegation set, and 
promptly denies the update if not (different from the create where there is a 
continuous check waiting for authority to appear). 

But this is likely due to .rio getting infrastructure from a ccTLD operator 
that happens to do similar checks… although in .br lack of DNS authority 
prevents registration, different from .rio. 

It’s not that pre-delegation checks add friction per se; it does if TLDs A, B, 
C do not perform them and TLDs X, Y and Z perform such checks. This makes other 
parties in network the graph (regardless of them being commercial, education, 
non-profit etc.) expect one behavior or the other, and fail in some regard when 
the practice of a TLD is different. 

But I will add one other party to the network graph that benefits from 
pre-delegation checks: Internet connectivity providers. Lame delegation makes 
DNS recursive servers to spend more resources to get no usable response, 
transferring load from registries/DNS operators/hosting companies to them. 

So, it would be really interesting if a standards-track document defines which 
behavior to follow so everyone can sing the same song. I just don’t see that 
happening. 


Rubens

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Mark Andrews]

> On 12 May 2023, at 12:09, John R Levine  wrote:
> 
>>> Yeah, that's a better way to put it. But the main point still stands,
>>> that it would be a signficant operational change to insist that all
>>> delegated NS be active when delegated, and even moreso to insist that
>>> they continue to be active.
>> 
>> No, it is not a “significant” change.  It should just be a minor extension
>> of the existing requirement to keep the NS and glue records consistent.
>> 
>> Even if it was you just introduce it with a soft start.  Just start checking
>> the delegations of every TLD like zone then report the broken servers
>> publicly and email the contacts for the delegation.  The tools for checking
>> already exist.
> 
> Well, OK, you do that, half the emails bounce, half of what's delivered is 
> reported as spam, and the third half are ignored.  Now what?

In practice it isn’t quite as bad as that.  Require registrars to refuse
renewals until the issues are addressed.  This is no different to not getting
your car’s registration renewed until it has past its safety inspection.

Mark

> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John R Levine]

Yeah, that's a better way to put it. But the main point still stands,
that it would be a signficant operational change to insist that all
delegated NS be active when delegated, and even moreso to insist that
they continue to be active.


No, it is not a “significant” change.  It should just be a minor extension
of the existing requirement to keep the NS and glue records consistent.

Even if it was you just introduce it with a soft start.  Just start checking
the delegations of every TLD like zone then report the broken servers
publicly and email the contacts for the delegation.  The tools for checking
already exist.


Well, OK, you do that, half the emails bounce, half of what's delivered is 
reported as spam, and the third half are ignored.  Now what?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Mark Andrews]

> On 12 May 2023, at 11:35, John Levine  wrote:
> 
> It appears that Mark Andrews   said:
>>> Oh, I completely agree.  My point was just that even in the root which is 
>>> small and you
>>> would hope would change slowly, it's still a challenge to track what's lame.
>> 
>> It’s not a challenge to track what is lame.  It’s dead simple.  You just 
>> have to look.  Getting
>> it addressed is the challenge.
> 
> Yeah, that's a better way to put it. But the main point still stands,
> that it would be a signficant operational change to insist that all
> delegated NS be active when delegated, and even moreso to insist that
> they continue to be active.

No, it is not a “significant” change.  It should just be a minor extension
of the existing requirement to keep the NS and glue records consistent.

Even if it was you just introduce it with a soft start.  Just start checking
the delegations of every TLD like zone then report the broken servers
publicly and email the contacts for the delegation.  The tools for checking
already exist.

RFC 4034, 4.2.2.

As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone. The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.

> Back in the 1990s when you registered names by email, NetSol checked
> that your NS were active before accepting them, but that was back when
> it was normal for the back and forth for registering a name to take a
> week.
> 
> R's,
> John

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Mark Andrews   said:
>> Oh, I completely agree.  My point was just that even in the root which is 
>> small and you
>> would hope would change slowly, it's still a challenge to track what's lame.
>
>It’s not a challenge to track what is lame.  It’s dead simple.  You just have 
>to look.  Getting
>it addressed is the challenge.

Yeah, that's a better way to put it. But the main point still stands,
that it would be a signficant operational change to insist that all
delegated NS be active when delegated, and even moreso to insist that
they continue to be active.

Back in the 1990s when you registered names by email, NetSol checked
that your NS were active before accepting them, but that was back when
it was normal for the back and forth for registering a name to take a
week.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Mark Andrews]

> On 9 May 2023, at 03:13, John Levine  wrote:
> 
> It appears that Kim Davies   said:
>> With that said, I think the root zone is probably not an instructive
>> use case for the broader question. Unlike typical zones, at the root it
>> can be said every delegation is to critical Internet infrastructure and
>> therefore the calculus around process complexity and efficiency would be
>> weighted differently.
> 
> Oh, I completely agree.  My point was just that even in the root which is 
> small and you
> would hope would change slowly, it's still a challenge to track what's lame.

It’s not a challenge to track what is lame.  It’s dead simple.  You just have 
to look.  Getting
it addressed is the challenge.

https://ednscomp.isc.org/compliance/tld-fullreport.txt has been generated daily 
for the last
5 years and the broken behaviours have stood out like sore thumbs the entire 
time.  It only takes
a couple of minutes to generate that report and that isn’t trying to go as fast 
as possible.

> R's,
> John
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Kim Davies   said:
>With that said, I think the root zone is probably not an instructive
>use case for the broader question. Unlike typical zones, at the root it
>can be said every delegation is to critical Internet infrastructure and
>therefore the calculus around process complexity and efficiency would be
>weighted differently.

Oh, I completely agree.  My point was just that even in the root which is small 
and you
would hope would change slowly, it's still a challenge to track what's lame.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Kim Davies]

Quoting John Levine on Saturday May 06, 2023:
> >The IANA Function Operator does so for all ccTLDs (which would imply all 
> >TLDs).
> 
> Indeed, but some of them are lame anyway.  Here's today's report:
> ... 
> There are 96 more that timed out but I can't tell whether they really aren't 
> there or it's a temporary network issue.

The IANA tests are only performed in the context of a change request
being processed. The current approach was put in place where there
was sensitivity against IANA monitoring TLDs. A third-party study was
commissioned last year that interviewed TLD operators and recommended
that approach evolve to proactive monitoring, so moving in that
direction is now something we are planning for.

With that said, I think the root zone is probably not an instructive
use case for the broader question. Unlike typical zones, at the root it
can be said every delegation is to critical Internet infrastructure and
therefore the calculus around process complexity and efficiency would be
weighted differently.

kim

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks

[Mark Elkins]

Back in 1995 when I took over the management of CO.ZA from Mike Lawrie, 
his strong suggestion was to only add properly functioning delegations 
to the Zone File - so that is what we did. Why add delegations that are 
broken to the working parent?


As a Registrar - if I am not providing the DNS for a Domain - then I 
have checks on my side to see if the Nameservers are working before 
sending them on to the Parent registry.


I also have a "Reservation" or Free service so that people can register 
a domain (using my Nameservers) but the domain is "read-only" on my side 
(no one can change any of the zone file contents). Point being - the 
delegation works if sent to a parent.


This all works fine.

In addition - I also manage the EDU.ZA and ALT.ZA zone files. These are 
both small zones and use the Registry/Registrant model (2 x R). Apart 
from running CDS checks, I also run weekly (Monday early morning) 
Nameserver checks so will see when things break and then email the 
domain owner of the event. Consequently - the two parent zones are 
pretty clean.


--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 



Posix SystemsVCARD for MJ Elkins

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks

[Peter Thomassen]

Hi Håvard,

On 5/7/23 01:10, Havard Eidnes wrote:

I guess it depends on what service the registry is actually
offering.

One way to look at it is that it's offering a service to extend the
public DNS name space to registrants.  In that scenario it makes
perfect sense to do a one-time check on initial registration or
update, with the intention of preventing the domain owner from
shooting himself in the foot.


How do you know it's a shot in the foot?

It's possible a registrant doesn't want to provide DNS service and just reserve the name. Or, as 
Joe said, it could be a name served only in some "internal" context. If not used 
publicly, that doesn't seem "unhealthy".

For *registration* checks, there was no DNS service so far, so nothing breaks 
if none is configured.

(The situation may be different if a delegation update breaks the delegation, 
which might warrant a warning.)


On the technical side, I don't think anyone has suggested to
introduce repeated checks with de-registration either of a single NS
or an entire domain on auto-polit.  Does any public registry
actually do that sort of thing?  I've never heard of it.  I call
that a straw man.


If you have a .is domain and you don't follow the requirements in [1] 
(including conditions on NS reachability and consistency, child-size NS RRset 
content and TTL, SOA MNAME/RNAME/timers), the operator will receive the 
following message:

The setup of zone .is on its nameservers appears not to be
according to ISNIC's requirements for .IS delegations.

Please see requirements [1] for information on these conditions.

Please make sure that the setup of domain .is is according to
the above conditions. The domain can be tested [2]

ISNIC will put on hold domains not fulfilling the delegation
requirements for extended periods. See article 21 in the .is
delegation rules. See our rules [3]

ISNIC will automatically park the domain if it is still non-compliant
after being on hold due to technical non-compliance for 30 days.

[1]: https://www.isnic.is/en/domain/req
[2]: https://www.isnic.is/en/domain/test?domain=.is
[3]: https://www.isnic.is/en/domain/rules#k6

Best,
Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Peter Thomassen]

Hi Joe,

On 5/5/23 20:45, Joe Abley wrote:

Pre-delegation checks add friction to the domain registration process.

[...]

To look at it another way, why would we give authority to a third party to 
break our domains just because they are not fully-informed about how we are 
using them?


+1

My suggestion was not to create guidance or a best practice document for 
pre-delegation checks, but rather that *if* such guidance were developed, it 
should very prominently say what *not* to do, precisely because too many checks 
cause too much friction.


And lastly, even if a delegation is genuinely broken and useless for all the 
world, and nobody cares enough to fix it, what harm does it do? What is the 
motivation to find a fix? A dribble of extra traffic relating to a 
mainly-unused domain to a nameserver that is already over-provisioned doesn't 
seem very compelling.


As a first reaction, I also agree with this (although I may be convinced by 
more data on cost/harm caused by the extra traffic, as Brian was hinting at).


Even if I thought this was a problem that needed a solution, I don't think the 
solution is likely to be easy.


Yes. It may be easier to just arrive at a document advising against certain 
checks, that is, a Worst Current Practice doc ;-)

Peter

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Mark Andrews]

> On 6 May 2023, at 04:45, Joe Abley  wrote:
> 
> Hi Peter,
> 
> On Fri, May 5, 2023 at 04:39, Peter Thomassen  wrote:
>> 
>> > Having the delegating party check for service for the requested zone
>> > at time of delegation request and refuse to update / register if
>> > this check fails
>> 
>> It would be interesting to develop a consensus position on acceptance checks 
>> for delegations. (Obviously, that's out of scope for this draft, so renaming 
>> the subject.)
> 
> 
> Pre-delegation checks add friction to the domain registration process. They 
> further complicate the commuications between different actors in the 
> commercial graph (registrars, registries, resellers, DNS operators, hosting 
> companies) and introduce delay and manual intervention into what might 
> otherwise be a fairly automated or at least automatable process. That is to 
> say, checks have a cost, and that cost might well be difficult to sell in a 
> commercial environment, especially one where the policy depends on a 
> membership that is often quite commercially motivated. (I appreciate not all 
> TLDs are the same.)

Then just have them all be post delegation checks.  If the servers listed are 
not serving within a week pull the delegation.

> The ability to arrive at a consistent universal policy across many different 
> policy regimes seems like a bit of a long shot. Some early adopters of 
> increased friction will be at a commercial disadvantage to late or 
> never-adopters of the same kinds of checks. This disadvantage will provide 
> further disincentive to adopt this kind of check for those registries that 
> are commercially-motivated. (I appreciate not all TLDs are 
> commercially-motivated.)
> 
> So even if a clear technical best current practice could be published, I 
> think there would be considerable work to do in seeing it implemented. I 
> presume implementation is desirable, otherwise we're just navel-gazing.
> 
> On the technical side, I think arriving at a generalised approach will be 
> difficult. For example,
> 
> 1. Repeated checks -- just because something is declared good at registration 
> time doesn't mean it might not go bad later. How often do you need to check?

Daily.  There are no zones where this is anything like impossible to do.  A 
single threaded process can do tens of thousands of requests a second and can 
be testing hundreds of thousands on delegations simultaneously.  We do this 
every day with the compliance checks on ednscomp.isc.org.

> 2. The possibility of cascading failure -- a partial failure in a delegation, 
> if punished by a domain suspension, might result in a complete failure. This 
> is at worst an attack vector and at best contrary to the interests of 
> stability for users of the Internet. Making automated changes to disable 
> things that are already demonstrably fragile seems a bit like form over 
> function.

So?  Stability of the DNS is already broken because of broken delegations and 
non RFC compliant server implementations.  It’s only mostly working at the 
moment because resolver vendors go to extraordinary lengths to work around the 
broken configurations and implementations.  No one is saying one strike and you 
are removed.  I would expect people to be given a reasonable amount of time to 
correct the issue along with repeated waring to multiple contacts.  That said 
once you start penalising broken behaviour people will learn that penalties 
will be applied and will proactively fix things that they know are being 
checked.

This is nothing more than the equivalent of a vehicle safety check.  For most 
checks the mechanic will say go get this fixed and come back to me in a few 
days for a re-check.  There are very few things where the mechanic says you 
can’t drive this car away as it is so unsafe that you shouldn’t be driving it, 
if you want to take the vehicle it needs to be on a flatbed.

> 3. Deliberately-incoherent namespaces -- many of the most common responses in 
> the DNS are generated at response time according to a variety of dynamic 
> policy, and are subject to access control. So vantage points matter. Any 
> policy that is measuring the health of a delegation needs to be able to 
> interpret the results of multiple measurements from different vantage points 
> and understand which of them correspond to a policy that is acceptable, 
> without any a priori understanding of what the response generation policy is. 
> In general I think this is problematic.

Please show a single instance where the delegation can’t be made coherent at 
the TLD level.  Nameservers and their addresses are relatively stable compared 
to everything else in the DNS.

> 4. The fiction of a single namespace. The particular bits of machinery that 
> respond to particular names and particular addresses (including nameserver 
> names and nameserver addresses) are not always the same. Private namespaces 
> exist that avoid collisions with the nominally-public namespace by maki

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Dr Eberhard W Lisse   said:
>The IANA Function Operator does so for all ccTLDs (which would imply all TLDs).

Indeed, but some of them are lame anyway.  Here's today's report:

FAIL ne. bow.rain.fr. 194.51.3.49 All nameservers failed to answer the query 
ne. IN SOA: Server 194.51.3.49 UDP port 53 answered REFUSED
FAIL ne. ns-ne.afrinic.net. 2001:43f8:120:0:0:0:0:45 All nameservers failed to 
answer the query ne. IN SOA: Server 2001:43f8:120:0:0:0:0:45 UDP port 53 
answered REFUSED
FAIL pg. ns1.tiare.net.pg. 202.165.192.23 All nameservers failed to answer the 
query pg. IN SOA: Server 202.165.192.23 UDP port 53 answered SERVFAIL
FAIL ss. b.ns.tznic.or.tz. 196.216.162.70 All nameservers failed to answer the 
query ss. IN SOA: Server 196.216.162.70 UDP port 53 answered SERVFAIL
FAIL tg. ns1.admin.net. 198.73.186.1 All nameservers failed to answer the query 
tg. IN SOA: Server 198.73.186.1 UDP port 53 answered SERVFAIL
FAIL ye. ns1.yemen.net.ye. 65.162.184.33 All nameservers failed to answer the 
query ye. IN SOA: Server 65.162.184.33 UDP port 53 answered SERVFAIL
FAIL ye. ns2.yemen.net.ye. 65.162.184.34 All nameservers failed to answer the 
query ye. IN SOA: Server 65.162.184.34 UDP port 53 answered SERVFAIL

There are 96 more that timed out but I can't tell whether they really aren't 
there or it's a temporary network issue.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks

[Joe Abley]

On Sat, May 6, 2023 at 19:10, Havard Eidnes <[h...@uninett.no](mailto:On Sat, 
May 6, 2023 at 19:10, Havard Eidnes < wrote:

> So, you're arguing that it would be "causing too much work"(?) for
> the registry to insist on having the registrant stand up a couple of
> public name servers to register the publically visible version of a
> domain? Really?

No. I'm predicting that finding agreement on the right technical criteria and 
appropriate actions will be difficult, and finding agreement on the policy side 
across many different policy regimes will be more difficult.

The difficulties I described were intended to illustrate that this is stuff is 
not necessarily easy, and that there are factors beyond the technical to think 
about. Whether it's too much work is a question for the working group, but I 
think it's a reasonable question.

Joe

>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks

[Havard Eidnes]

> Pre-delegation checks add friction to the domain registration
> process. They further complicate the commuications between
> different actors in the commercial graph (registrars, registries,
> resellers, DNS operators, hosting companies) and introduce delay
> and manual intervention into what might otherwise be a fairly
> automated or at least automatable process. That is to say, checks
> have a cost, and that cost might well be difficult to sell in a
> commercial environment, especially one where the policy depends on
> a membership that is often quite commercially motivated. (I
> appreciate not all TLDs are the same.)

Oh, yes, the sanctity of making a buck, "we can't let any technical
obstacle get in it's way", and by extension "contributing to
maintaining the good health of the public DNS doesn't really matter,
as long as we get to collect the registration fees."

I guess it depends on what service the registry is actually
offering.

One way to look at it is that it's offering a service to extend the
public DNS name space to registrants.  In that scenario it makes
perfect sense to do a one-time check on initial registration or
update, with the intention of preventing the domain owner from
shooting himself in the foot.

Another way would be to look at it as purely a name space
administration issue, i.e. just ensure uniqueness, and let loose the
commercial folks with their "product innovations" and "improved
efficiency" aims, casting aside quite a few technical considerations
for the public DNS.

In case you haven't noticed, I have a distaste for the latter, and
a number of registries operate with the former model.


On the technical side, I don't think anyone has suggested to
introduce repeated checks with de-registration either of a single NS
or an entire domain on auto-polit.  Does any public registry
actually do that sort of thing?  I've never heard of it.  I call
that a straw man.

> On the technical side, I think arriving at a generalised approach
> will be difficult. For example,
>
> 1. Repeated checks -- just because something is declared good at
>registration time doesn't mean it might not go bad later. How
>often do you need to check?

You are assuming too much here, I think, in particular what the goal
is and what the a reasonable mechanism to attain that goal could be.
I've not argued to "outlaw inconsistencies or lameness", and it is
true that such errors may be introduced over time outside of the
interactions with the registry.  What I have argued is that it's
probably a good idea to check for consistency & service on the time
of registration or update.

> 2. The possibility of cascading failure -- a partial failure in a
>delegation, if punished by a domain suspension, might result in
>a complete failure. This is at worst an attack vector and at
>best contrary to the interests of stability for users of the
>Internet. Making automated changes to disable things that are
>already demonstrably fragile seems a bit like form over
>function.

Again, here you're assuming that something doing a repeated check
will automatically de-register a domain on auto-pilot.  I certainly
have not argued for such a thing, and would find the suggestion
absurd.

> 3. Deliberately-incoherent namespaces -- many of the most common
>responses in the DNS are generated at response time according
>to a variety of dynamic policy, and are subject to access
>control. So vantage points matter. Any policy that is measuring
>the health of a delegation needs to be able to interpret the
>results of multiple measurements from different vantage points
>and understand which of them correspond to a policy that is
>acceptable, without any a priori understanding of what the
>response generation policy is. In general I think this is
>problematic.

I don't think this is problematic at all.  If a registrant wants to
do "private stuff" with his domain, he'd do best in keeping that
private, and the effects of that out of visibility for the registry.
The registry should be checking the publically visible data, and is
unlikely to have a probe for consistency checking within a "private
DNS zone" of a registrant.  And ... if you really insist on doing
violence to the DNS standards and expectations of consistency,
you're of course free to do whatever dirty deeds you have convinced
yourself you need to do in a subdomain / sub-zone of your properly
functioning public DNS domain.

> 4. The fiction of a single namespace. The particular bits of
>machinery that respond to particular names and particular
>addresses (including nameserver names and nameserver addresses)
>are not always the same. Private namespaces exist that avoid
>collisions with the nominally-public namespace by making the
>same companyname.com domain exist in both, but implementing
>each very differently. This is valid and good advice, even
>(e.g. compared to squatting on .HOME or .CORP)

Re: [DNSOP] Delegation acceptance checks

[Dr Eberhard W Lisse]

Håvard,

ccNSO has no role to play here.

Each ccTLD makes its own rules, and not that it matters, being tiny,
.NA does require working name servers (at registration, and when we
check on it).

el

On 05/05/2023 19:01, Havard Eidnes wrote:
>>> I imagine that others also spend time on sorting out these entirely
>>> unnecessary issues.  If guidance were developed on delegation
>>> acceptance checks,
>>
>> Well, yes... but where?
> 
> ccNSO, perhaps?
> 
> My advice would be to only enforce checks where violations would
> negatively impact operations (e.g. disallow lame delegation setups),
> and not enforce pure "dotting the i's and crossing the t's"
> requirements where doing so contributes minimal to no improvement
> operationally.
> 
>> To me it feels like the IETF would be the right place to discuss and
>> develop the guidance (personally I think that a parent should check if the
>> name servers that are being proposed actually answer for the domain[0], and
>> strongly suggest (but do not prevent) that that be fixed[1].
> ...
>> [0]: Some, including myself, would call this lame, but...
> 
> Yup.
> 
> I personally think that if a ccTLD insists on non-lame delegations at
> the time of registration or update, I would not object.
> 
>> [1]: As an example, I have a-random-test-domain.net pointing to
>> nameservers which have no idea about this domain - and I did that
>> intentionally...
> 
> There's of course always the option of doing your own dirty work in a
> child zone of your own properly delegated and operational domain.
> 
> Regards,
> 
> - Håvard

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht  \  /  If this email is signed with GPG/PGP
10007, Namibia   ;/ Sect 20 of Act No. 4 of 2019 may apply

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Dr Eberhard W Lisse]

The IANA Function Operator does so for all ccTLDs (which would imply
all TLDs).

el

On 06/05/2023 17:20, John Levine wrote:
> It appears that Joe Abley   said:
>> Pre-delegation checks add friction to the domain registration
>> process.  They further complicate the commuications between different
>> actors in the commercial graph (registrars, registries, resellers,
>> DNS operators, hosting companies) and introduce delay and manual
>> intervention into what might otherwise be a fairly automated or at
>> least automatable process.  ...
> 
> Thirty years ago, when you did domain registrations by e-mail, the
> registry which was then called Network Solutions did indeed check that
> your name servers were active before delegating the domain.  It was
> not an accident that they stopped doing so, and it seems vanishingly
> unlikely that any gTLD registry would do so now, regardless of what
> people here might think.

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421 Bachbrecht  \  /  If this email is signed with GPG/PGP
10007, Namibia   ;/ Sect 20 of Act No. 4 of 2019 may apply

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[John Levine]

It appears that Joe Abley   said:
>Pre-delegation checks add friction to the domain registration process. They 
>further complicate the commuications between different actors in the 
>commercial graph
>(registrars, registries, resellers, DNS operators, hosting companies) and 
>introduce delay and manual intervention into what might otherwise be a fairly 
>automated
>or at least automatable process. ...

Thirty years ago, when you did domain registrations by e-mail, the
registry which was then called Network Solutions did indeed check that
your name servers were active before delegating the domain. It was not
an accident that they stopped doing so, and it seems vanishingly
unlikely that any gTLD registry would do so now, regardless of
what people here might think.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Brian Dickson]

On Fri, May 5, 2023 at 11:46 AM Joe Abley  wrote:

> Hi Peter,
>
> On Fri, May 5, 2023 at 04:39, Peter Thomassen  > wrote:
>
> > Having the delegating party check for service for the requested zone
> > at time of delegation request and refuse to update / register if
> > this check fails
>
> It would be interesting to develop a consensus position on acceptance
> checks for delegations. (Obviously, that's out of scope for this draft, so
> renaming the subject.)
>
>
> Pre-delegation checks add friction to the domain registration process.
> They further complicate the commuications between different actors in the
> commercial graph (registrars, registries, resellers, DNS operators, hosting
> companies) and introduce delay and manual intervention into what might
> otherwise be a fairly automated or at least automatable process. That is
> to say, checks have a cost, and that cost might well be difficult to sell
> in a commercial environment, especially one where the policy depends on a
> membership that is often quite commercially motivated. (I appreciate not
> all TLDs are the same.)
>
> The ability to arrive at a consistent universal policy across many
> different policy regimes seems like a bit of a long shot. Some early
> adopters of increased friction will be at a commercial disadvantage to late
> or never-adopters of the same kinds of checks. This disadvantage will
> provide further disincentive to adopt this kind of check for those
> registries that are commercially-motivated. (I appreciate not all TLDs are
> commercially-motivated.)
>
> So even if a clear technical best current practice could be published, I
> think there would be considerable work to do in seeing it implemented. I
> presume implementation is desirable, otherwise we're just navel-gazing.
>
> On the technical side, I think arriving at a generalised approach will be
> difficult. For example,
>
> 1. Repeated checks
>
[snip]
There is also the notion of indirect checks vs direct checks, with
reporting/signaling/scaling elements.
I think the work on trust anchors (done for gathering information to inform
the root key rollover) would be one relevant example to consider.
Other work (recent or in progress) related to reporting to domain operators
(don't recall draft or rfc identifiers) would also be useful to examine.

3. Deliberately-incoherent namespaces
>
[snip]
This is definitely something that any proposal should accommodate. One
approach would be looking at opt-in vs opt-out mechanisms, possibly
anchored under the namespaces of NS names.
Scaling for all of these sorts of mechanisms is also very important, given
that the first priority of the DNS system is answering queries, and
anything that impacts performance needs to be tempered appropriately.


> To look at it another way, why would we give authority to a third party to
> break our domains just because they are not fully-informed about how we are
> using them?
>

This is an important consideration, for sure.

I think any proposals should start with a couple of things;

   1. Identifying what parties are interested parties and/or involved
   parties. Depending on specifics the number could be large, but in the
   general case there is a minimum number of parties that are necessarily
   involved. Enumerating those, and what their roles in would be a good place
   to start.
   2. Determining authority tied to those parties and their roles. The
   canonical example would be the operator of a name server, should be
   involved in decisions about whether or not a given delegation should be
   allowed when the domain is not served by the name server.



>
> And lastly, even if a delegation is genuinely broken and useless for all
> the world, and nobody cares enough to fix it, what harm does it do? What is
> the motivation to find a fix? A dribble of extra traffic relating to a
> mainly-unused domain to a nameserver that is already over-provisioned
> doesn't seem very compelling.
>

This is where I can add some useful data and context.
Operators of substantial numbers of zones where this traffic is received
are able to quantify the impact.
At the servers under domaincontrol dot com, the normal traffic is over 15%
queries for domains not served (i.e. lame zone delegations). That is a lot.
Additionally, lame delegations are abuse vectors. We see much abuse via
this vector.
And lastly, the current state of affairs is that we are unable to directly
affect this, since the RRR model does not include a role for DNS operators.
(We are also a Registrar, but when the domain has a different Registrar
than us, the RRR rules do not facilitate us removing lame delegations to
our name servers.)

I do have some ideas on mechanisms, but those probably belong in their own
thread.

I.e. the issue isn't specifically "pre-delegation checks", it is
"delegation correction".


> Even if I thought this was a problem that needed a solution, I don't think
> the solution is likely to be easy. The technical aspects are the

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Joe Abley]

Hi Peter,

On Fri, May 5, 2023 at 04:39, Peter Thomassen <[pe...@desec.io](mailto:On Fri, 
May 5, 2023 at 04:39, Peter Thomassen < wrote:

>> Having the delegating party check for service for the requested zone
>> at time of delegation request and refuse to update / register if
>> this check fails
>
> It would be interesting to develop a consensus position on acceptance checks 
> for delegations. (Obviously, that's out of scope for this draft, so renaming 
> the subject.)

Pre-delegation checks add friction to the domain registration process. They 
further complicate the commuications between different actors in the commercial 
graph (registrars, registries, resellers, DNS operators, hosting companies) and 
introduce delay and manual intervention into what might otherwise be a fairly 
automated or at least automatable process. That is to say, checks have a cost, 
and that cost might well be difficult to sell in a commercial environment, 
especially one where the policy depends on a membership that is often quite 
commercially motivated. (I appreciate not all TLDs are the same.)

The ability to arrive at a consistent universal policy across many different 
policy regimes seems like a bit of a long shot. Some early adopters of 
increased friction will be at a commercial disadvantage to late or 
never-adopters of the same kinds of checks. This disadvantage will provide 
further disincentive to adopt this kind of check for those registries that are 
commercially-motivated. (I appreciate not all TLDs are commercially-motivated.)

So even if a clear technical best current practice could be published, I think 
there would be considerable work to do in seeing it implemented. I presume 
implementation is desirable, otherwise we're just navel-gazing.

On the technical side, I think arriving at a generalised approach will be 
difficult. For example,

1. Repeated checks -- just because something is declared good at registration 
time doesn't mean it might not go bad later. How often do you need to check?

2. The possibility of cascading failure -- a partial failure in a delegation, 
if punished by a domain suspension, might result in a complete failure. This is 
at worst an attack vector and at best contrary to the interests of stability 
for users of the Internet. Making automated changes to disable things that are 
already demonstrably fragile seems a bit like form over function.

3. Deliberately-incoherent namespaces -- many of the most common responses in 
the DNS are generated at response time according to a variety of dynamic 
policy, and are subject to access control. So vantage points matter. Any policy 
that is measuring the health of a delegation needs to be able to interpret the 
results of multiple measurements from different vantage points and understand 
which of them correspond to a policy that is acceptable, without any a priori 
understanding of what the response generation policy is. In general I think 
this is problematic.

4. The fiction of a single namespace. The particular bits of machinery that 
respond to particular names and particular addresses (including nameserver 
names and nameserver addresses) are not always the same. Private namespaces 
exist that avoid collisions with the nominally-public namespace by making the 
same companyname.com domain exist in both, but implementing each very 
differently. This is valid and good advice, even (e.g. compared to squatting on 
.HOME or .CORP). Should those domains be suppressed simply because they are not 
intended for use by the general public?

My personal opinion on all of this is that there is already direct commercial 
pressure for delegations to be healthy when they matter. Services that depend 
on the DNS (or things reached by the DNS) that people care about generally have 
incentives to keep their ducks lined up (incentives like revenue, customer 
retention, being elected again). Things in the DNS that aren't well-paired with 
incentives like that might well break more often, but if a delegation breaks in 
the forest and there's nobody present to argue about whether the delegation is 
strictly lame or not, does anybody need to care?

To look at it another way, why would we give authority to a third party to 
break our domains just because they are not fully-informed about how we are 
using them?

And lastly, even if a delegation is genuinely broken and useless for all the 
world, and nobody cares enough to fix it, what harm does it do? What is the 
motivation to find a fix? A dribble of extra traffic relating to a 
mainly-unused domain to a nameserver that is already over-provisioned doesn't 
seem very compelling.

Even if I thought this was a problem that needed a solution, I don't think the 
solution is likely to be easy. The technical aspects are the easiest part, and 
those are already difficult. Perhaps we can just become comfortable with the 
idea that at any time the DNS contains bits that work and bits that don't work, 
and that is ju

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Mark Delany]

On 05May23, Warren Kumari apparently wrote:

> I think that a parent should check if the name servers that are
> being proposed actually answer for the domain[0], and strongly
> suggest (but do not prevent) that that be fixed[1].

"Strongly suggest" is definitely as far as I would go because you may
have a bit if a chicken and egg problem. Some processes may prefer to
configure the parent first while others may wish to configure the
delegated name servers first.

More specifically, I have a no-configuration reverse server which
deduces its NS details from the delegation (the goal being to minimize
duplication of configuration information). It's impossible for it to
be configured and serve correctly without first gaining information
from the delegating parent.


Mark.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks

[Havard Eidnes]

>> I imagine that others also spend time on sorting out these entirely
>> unnecessary issues. If guidance were developed on delegation acceptance
>> checks,
>
> Well, yes... but where?

ccNSO, perhaps?

My advice would be to only enforce checks where violations would
negatively impact operations (e.g. disallow lame delegation setups),
and not enforce pure "dotting the i's and crossing the t's"
requirements where doing so contributes minimal to no improvement
operationally.

> To me it feels like the IETF would be the right place to discuss and
> develop the guidance (personally I think that a parent should check if the
> name servers that are being proposed actually answer for the domain[0], and
> strongly suggest (but do not prevent) that that be fixed[1].
...
> [0]: Some, including myself, would call this lame, but...

Yup.

I personally think that if a ccTLD insists on non-lame delegations at
the time of registration or update, I would not object.

> [1]: As an example, I have a-random-test-domain.net pointing to
> nameservers which have no idea about this domain - and I did that
> intentionally...

There's of course always the option of doing your own dirty work in a
child zone of your own properly delegated and operational domain.

Regards,

- Håvard

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Warren Kumari]

On Fri, May 05, 2023 at 4:39 AM, Peter Thomassen  wrote:

> On 5/4/23 20:07, Havard Eidnes wrote:
>
> As an example, it's quite common for people to register a domain and point
> the DNS at some nameservers which they don't control, and have no
> relationship with.
>
> If this is common, I'm abhorred.
>
> Having the delegating party check for service for the requested zone at
> time of delegation request and refuse to update / register if this check
> fails
>
> It would be interesting to develop a consensus position on acceptance
> checks for delegations. (Obviously, that's out of scope for this draft, so
> renaming the subject.)
>
> I can see some value in such delegation checks. However, I think that very
> clear guidance on what kinds of checks are acceptable would be helpful, to
> avoid checks that primarily cause trouble. Examples:
>
> - DENIC customers have repeatedly reported to us (deSEC) DENIC's warning
> on how our SOA REFRESH and RETRY values should be related. We think it's
> entirely a matter of how the operator arranges their replication, and the
> parent should not be concerned. What's more, the DENIC recommendations are
> in contradiction to RIPE's. [1]
>
> - Lots of tools and some registries check reachability and other
> configuration details of the SOA MNAME, although the MNAME again is an
> internal matter to the operator. (Could be using a different replication
> scheme; could be a split-horizon setup; ...) For example, NIC.it
>  rejects nameservers whose SOA MNAME is a CNAME [2].
> Tools like MxToolbox, Zonemaster etc. trigger warnings when the SOA MNAME
> has no DNS service [3]. Other tools complain when the MNAME isn't
> dual-stack [4]. We receive similar complaints about the "serial date being
> in the future".
>
> - ISNIC recently started rejecting new delegation to deSEC (and warned to
> delete existing ones) because our zones allegedly don't have NS records. It
> turned out that their delegation tool did not honor the extended RCODE
> field (RFC 6891) which is why BADCOOKIE appeared like YXRRSET to them, and
> the tool gave up. (No public reference though, and it's been fixed within a
> few days.)
>
> While I'm not generally opposed to parents checking whether a delegation
> update would break the domain's resolution (this is like the CDS acceptance
> checks, and makes sense for NS, too), I do see some risk in encouraging
> people to do more checks.
>
> I imagine that others also spend time on sorting out these entirely
> unnecessary issues. If guidance were developed on delegation acceptance
> checks,
>


Well, yes… but where?

To me it feels like the IETF would be the right place to discuss and
develop the guidance (personally I think that a parent should check if the
name servers that are being proposed actually answer for the domain[0], and
strongly suggest (but do not prevent) that that be fixed[1].

As the most common place where this occurs is (citation needed!) at a TLD,
I'd think that once guidance is created, someone (SSAC?) should push for it
being strongly recommended / folded into ICANN contract.

it would be great to use the opportunity not only to encourage helpful
> checks, but also to discourage harmful ones.
>

Yup.

I think that these should be of the forms "SHOULD / SHOULD NOT /
RECOMMENDED", and not of the form "MUST / MUST NOT" — if I want to do
something silly with a domain, I should be able to (as long as it isn't
harming others).


W
[0]: Some, including myself, would call this lame, but….
[1]: As an example, I have a-random-test-domain.net pointing to
nameservers which have no idea about this domain - and I did that
intentionally…




> Thanks,
> Peter
>
> [1]: https://talk.desec.io/t/
> default-soa-does-not-match-denic-recommendations/520/2
> [2]: https://talk.desec.io/t/
> nic-it-cnamehosttest-failed-changing-nameservers/432
> [3]: https://talk.desec.io/t/invalid-soa-record/68
> [4]: https://talk.desec.io/t/reachability-of-digga-desec-io/339
>
> --
> https://desec.io/
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Peter Thomassen]

On 5/4/23 20:07, Havard Eidnes wrote:

As an example, it's quite common for people to register a
domain and point the DNS at some nameservers which they don't
control, and have no relationship with.


If this is common, I'm abhorred.

Having the delegating party check for service for the requested zone
at time of delegation request and refuse to update / register if
this check fails


It would be interesting to develop a consensus position on acceptance checks 
for delegations. (Obviously, that's out of scope for this draft, so renaming 
the subject.)

I can see some value in such delegation checks. However, I think that very 
clear guidance on what kinds of checks are acceptable would be helpful, to 
avoid checks that primarily cause trouble. Examples:

- DENIC customers have repeatedly reported to us (deSEC) DENIC's warning on how 
our SOA REFRESH and RETRY values should be related. We think it's entirely a 
matter of how the operator arranges their replication, and the parent should 
not be concerned. What's more, the DENIC recommendations are in contradiction 
to RIPE's. [1]

- Lots of tools and some registries check reachability and other configuration details of 
the SOA MNAME, although the MNAME again is an internal matter to the operator. (Could be 
using a different replication scheme; could be a split-horizon setup; ...) For example, 
NIC.it rejects nameservers whose SOA MNAME is a CNAME [2]. Tools like MxToolbox, 
Zonemaster etc. trigger warnings when the SOA MNAME has no DNS service [3]. Other tools 
complain when the MNAME isn't dual-stack [4]. We receive similar complaints about the 
"serial date being in the future".

- ISNIC recently started rejecting new delegation to deSEC (and warned to 
delete existing ones) because our zones allegedly don't have NS records. It 
turned out that their delegation tool did not honor the extended RCODE field 
(RFC 6891) which is why BADCOOKIE appeared like YXRRSET to them, and the tool 
gave up. (No public reference though, and it's been fixed within a few days.)

While I'm not generally opposed to parents checking whether a delegation update 
would break the domain's resolution (this is like the CDS acceptance checks, 
and makes sense for NS, too), I do see some risk in encouraging people to do 
more checks.

I imagine that others also spend time on sorting out these entirely unnecessary 
issues. If guidance were developed on delegation acceptance checks, it would be 
great to use the opportunity not only to encourage helpful checks, but also to 
discourage harmful ones.

Thanks,
Peter

[1]: 
https://talk.desec.io/t/default-soa-does-not-match-denic-recommendations/520/2
[2]: 
https://talk.desec.io/t/nic-it-cnamehosttest-failed-changing-nameservers/432
[3]: https://talk.desec.io/t/invalid-soa-record/68
[4]: https://talk.desec.io/t/reachability-of-digga-desec-io/339

--
https://desec.io/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop