> 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 231
> 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 ter
>> 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
> wi
>> 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 impro
>> 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 names
>> > ; 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 ag
> 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
>> > 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
> 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. Ident
>>"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
>> "l
> 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 simpl
> 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 bee
> 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
> 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
>> 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
> 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 mig
> 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 it's
> 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,
> https://author-tools.ietf.org/iddif
>> 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 fut
> 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:
> example
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
_
>>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 r
>>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 min
>> 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 toothpick
>>> 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
>>> good
> 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 nameserv
>- 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 n
>> 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 p
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 primary
>> 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.
Rea
>> 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 DNSSEC-signing-on-the-
>> 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 not
>> > 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 (
>> 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 la
>> 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 regist
> 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 lam
> 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, althoug
>>> 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
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 un
>> 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
>
>> However in the child-centric case this can cause problems when the
>> NS set held by the parent changes (i.e. the zone is redelegated) but
>> the NS set in the old set of servers isn't also updated. Such a
>> child-centric resolver may completely fail to notice the
>> redelegation.
>
> Yes, thi
>>Firstly, isn't this "child-centric resolver" / "parent-centric
>>resolver" simply an euphemism papering over the more distinct
>>"correctly" and "wrongly" implemented resolver?
>
> That's my thought exactly. (But that doesn't mean the terms
> needn't be given definitions.)
...
>>>Phantom domai
>> > 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
43 matches
Mail list logo
