>>In my mind this is good enough reason to outlaw keytag collisions -
>>without them it would be _much_ easier to implement reasonable limits
>>without risk of breaking legitimate clients.
>
> That would make key tags meaningful. ;--)
That may be an inevitable consequence. To my
>>Stupid question time:
>>
>>> The target of a DELEG alias cannot be stored in the child
>>> zone. It would not resolve if you do.
>>
>> Doesn't this mean that we can never get to an environment where
>> there only exists DELEG records and no NS records, and still have
>> a working DNS?
>
> DELEG
Stupid question time:
> The target of a DELEG alias cannot be stored in the child
> zone. It would not resolve if you do.
Doesn't this mean that we can never get to an environment where
there only exists DELEG records and no NS records, and still have
a working DNS?
Regards,
- Håvard
> We have been looking at some DNS resolvers and encountered a question:
>
> When a DNS response contains (in the answer section) records which were
> not requested, how should the resolver react to those and what should
> it return to the requesting client?
>
> For example:
>
> QUESTION:
>
>> Note that Scott's current EPP draft is still using this term,
>> citing the definition in 1912. Should the term be removed
>> from Scott's draft, or acknowledged that it is now historic?
>> If Scott replaces it with another more precise term, can we
>> get that term in this document so that
> With the DNSOP interim meeting last June, we reworded the definition
> of "lame delegation". This new definition of "lame delegation" has
> been shared on the mailing list and included by the document authors
> in the latest revision of the rfc8499bis draft,
>
> Then, how about we stop using "lame delegation" and use terms like
> "imperfect delegation" or "incomplete delegation"?
Hm, not sure I like either of those two alternatives. I'll give
my reasons. In general, to my ear they sound very "generic".
A delegation may be "perfect", meaning that
> 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
>> 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
> 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
> I have one last question. Regardless of whether we agree
> precisely on what "lame" means, what is the call to action when
> a zone or its name servers are declared lame?
"Get your ducks in a row!"
A domain owner is presumably normally interested in name
resolution for names in his/hers domain
> A lame delegation is said to exist when a server assumed (by
> the querier) to be authoritative for a zone replies
> non-authoritatively for {any|all} data within the zone.
...
> 3) {any|all} open question...can a server be "partially lame?"
Sadly, yes, ref. suspected load balancers who have
> My parent says that the NS for exmple.com are ns1.example.com,
> ns2.example.com , but I (example.com) say that my NS are ns1.example.com,
> ns2.example.com *and* ns3.example.com. I don't (personally) think that this
> is a lame delegation. Do others?
Nope. Given this information, this is
>>"A lame delegation is said to exist when one or more authoritative
>>servers designated by the delegating NS RRset or by the child's apex
>>NS RRset answers non-authoritatively [or not at all] for a zone".
>>
>> ... without the "or not at all" part (so, an answer is required for
>>
> Joe Abley> One nameserver in the delegation set of a particular
> Joe Abley> child zone might provide non-authoritative
> Joe Abley> responses. By my usage, that nameserver is lame for
> Joe Abley> that zone. The delegation of that zone to that
> Joe Abley> nameserver is a lame delegation.
>> > Well, one would, in fact, expect a delegation to be a
>> > non-authoritative answer:
>>
>> Yes, but one would presume that before any of the two above
>> queries were sent, the recursive resolver already have cached the
>> delegation for jshsos.ksyunv5.com.
>
> It doesn't matter, there can be
> What I'm trying to suggest (resolver perspective), is that
> questions of responsibility, ... are not something a resolver
> can or should attempt to determine. All one can attempt to do
> is classify query responses.
Yes, I agree, as far as a recursive resolver is concerned.
However, talking
>> > ; ANSWER
>> > ; AUTHORITY
>> > example.com. IN NS ns1.provider.net.
>> > example.com. IN NS ns2.provider.net.
>> >
>> > is a valid delegation response (and so not from this perspective a LAME
>> > delegation), whether or not the target servers actualy serve the zone.
>>
>> I
>> I believe that the most natural perspective is from the view point of a
>> resolver attempting to classify a (non?)response to a query sent to an
>> authoritative server.
>
> Another way of thinking about this perspective is that, e.g., a
> delegation response from a.gtld-servers.net (.COM
>> We welcome the working group's thoughts whether "lame delegation"
>> encompasses these three possibilities.
>
> FYI, when working on the EDE draft [RFC8914] we discussed lame
> delegations some and actually did not document a particular error code
> related to it, as the meaning both uses
>> There are three possible situations in which this might be
>> considered a lame delegation:
>
> (4) What if NS.EXAMPLE.ORG does respond to EXAMPLE.NET queries
> but claims that the correct name server is NS.EXAMPLE.COM?
>
> Does that make the delegation NS "lame" since resolvers
>
> Dear DNSOP,
>
> I am participating in an SSAC work party where we are writing
> about DNS delegations where a delegated name server might be
> available for registration, allowing an attacker to participate in
> the resolution for the domain. During report drafting we
> considered using the
> Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it occured
> to me that the automatic reverse that
> draft-ietf-homenet-naming-architecture-dhc-options could enable
> better/simpler RFC2317 delegation for IPv4 subnets.
>
> My experience is that some of the pushback for doing
>> On Apr 25, 2022, at 11:20 AM, Petr Menšík wrote:
>> I think the only good way would be starting considering shorter keys as
>> insecure in FIPS mode.
>
> Agreed. We've been using 2408-bit ZSKs for more than ten years
> now. It's definitely time to sunset acceptance of shorter keys
> at this
>- Switching providers while staying secure requires
>inter-provider cooperation, including publishing ZSKs from
>both providers in the DNSKEY RRSET served by both providers.
What?
Maybe I just don't understand the context or conditions here, but
...
Isn't it possible to stand up a
> During the last hackathon at IETF-109, a new idea emerged where the
> version of a member zone in a catalog (indicated by the member zone's
> SOA serial number) is also in the catalog. This can help ensuring
> dissemination of member zones in a catalog from the primary to the
> secondary
>>> by the way, this is what kato and i, and later jabley, were
>>> trying to get at with
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/
>>>
>>> but it was like moving mud with a toothpick, so after eleven
>>> years (2003 to 2014) we gave it up. there are probably some
>>>
>> this is the draft where that issue would be decided, so it's
>> good we're talking about it. ...
>
> by the way, this is what kato and i, and later jabley, were
> trying to get at with
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-respsize/
>
> but it was like moving mud with a
>> > except that we heard at the side meeting in Montreal (albeit from
>> > browser people rather than content people) that they *don't* want
>> > SRV, because it has fields that are not compatible with the web
>> > security model.
>>
>> Can you summarize the particulars of the web security model
>> I also feel from this discussion, we are all roughly on the same
>> page. We want SRV as the long term solution ...
>
> except that we heard at the side meeting in Montreal (albeit from
> browser people rather than content people) that they *don't* want
> SRV, because it has fields that are
>> If I look up foo and it has an ANAME to bar, which of these do I get
>> back?
>
> ; ANSWER SECTION
> foo. A 1.2.3.4
Who provides the DNSSEC proof for this record? AIUI, there is no
A 1.2.3.4 in the "foo." zone originally, but there is an ANAME.
How, then, does this avoid
>> Secondly: can someone please explain to me why the idea of a
>> "primary master" where the zone data originates from and where
>> updates are performed is considered archaic?
>
> I think the only in-protocol use of the MNAME field is to
> specify the name to which UPDATE messages are sent.
Hi,
draft 07 says:
Primary master: "The primary master is named in the zone's SOA MNAME
field and optionally by an NS RR". (Quoted from [RFC1996],
Section 2.1). [RFC2136] defines "primary master" as "Master
server at the root of the AXFR/IXFR dependency graph. The
>>> If something gets an ANY response that does not include the thing it
>>> really needs, how is it supposed to know that it needs to ask again?
>>
>> If something is unable to unambiguously ask for the exact thing it
>> really needs, that's their problem. It's not a concern for this WG or
>> the
> consider a nameserver ns.example.com serving example.com. There is a
> delegation from com. including glue.
> Now we add a childzone sub.example.com. served by the same nameserver
> ns.example.com.
>
> should I add a entry in example.com to delegate the subzone to myself?
Generally, yes,
> When I did inspection of "lameness" I ran across the definition
> of a lame server (in a few RFCs) being a name server, named in
> an NS set that responded that it was not authoritative for the
> answer sought.
>
> I cannot say that I have ever seen a definition of a lame
> delegation, just a
>> It may not be possible for everyone to agree on a comprehensive
>> set of 'wrongs' with no omissions, but it should be possible to
>> get consensus on a core set of 'wrongs' that are not controversial.
>
> Yes and no. I think going for a minimum will be a good goal,
> but for example to have
>> Does the scenario look like this?
>>
>> * Client asks to registrar to set up frobbit.se
>
> Yes, someone want to register frobbit.se domain name. For pure
> IPR reasons. It should not resolve.
Ah, OK. Then this is first and foremost a registry policy issue:
do you in your policy support
Child-centric resolver: a DNS resolver which will replace, in its
memory, the NS RRset and glue records obtained from the parent, by
data from the authoritative servers of the zone they belong to. This
is the proper behaviour (but note that a resolver MUST re-check from
the parent at
Hi,
I wonder if I could please have someone say whether they agree
with me on this one:
I've come across a configuration in the wild where a given zone
'z' contains both
a.z. NS some.name.server.
*and*
sub.a.z. NS some.other.name.server.
and where the owner of 'a.z' could not
I've come across a configuration in the wild where a given zone
'z' contains both
a.z. NS some.name.server.
*and*
sub.a.z. NS some.other.name.server.
are some.name.server and some.other.name.server really
different servers? Different instances of name server
software(not only
41 matches
Mail list logo
