Re: [dns-operations] why does that domain resolve?

[Adam David]

I would concur, dnschecker shows incorrect information. I feel that it
could be their recursive dns failing to provide correct responses, or a
coding error?

Either way, I wouldn't use it.

When I check using "dig" all records show correctly.

Using mxtoolbox.com is another option if you are not familiar with "dig"
and the applicable RFCs.

Adam

On Mon., Jun. 14, 2021, 10:04 a.m. Dave Lawrence,  wrote:

> Tony Finch writes:
> > > So, what are people's favorite tools, especially those that you can
> just
> > > point a user at?
> >
> > I wouldn't point a user at any of these unless I think they have a good
> > amount of DNS expertise :-)
>
> Indeed.  I recently had to field a complaint that invoked an analysis
> by https://dnschecker.org/domain-health-checker.php as being related
> to problems someone was seeing.  That report didn't show errors, but
> of the eight warnings that it issued--and that the reporter thought
> needed attention--they were either incorrect, irrelevant, inscrutable,
> or simply wrong.
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Mark Delany]

On 14Jun21, Dave Lawrence allegedly wrote:
> > I wouldn't point a user at any of these unless I think they have a good
> > amount of DNS expertise :-)
> 
> Indeed.  I recently had to field a complaint that invoked an analysis
> by https://dnschecker.org/domain-health-checker.php as being related

Not sure it's fair to say that DNS checking tools are beyond the capabilities 
of the
average domain admins, which is what I was originally asking about. Beyond Joe 
Public,
sure.

Not that I disagree with your observation about dnschecker; it clearly suffers 
from a lack
of focus and a lot of scope-creep. One minute it's checking your delegation 
path, next
minute it's making SMTP connections to your mail servers.

The tool I've found most useful for relatively novice domain admins is one 
which simply
verifies the things they can break - namely their zone files, name servers and 
delegation
details.

 $ Fat-finger my zone files
 $ distribute
 $ if ! `my-dns-ok`; then echo Panic Stations; else echo All good; fi
 
Beyond that either provides too much information or provides information which 
they find
impossible to act on such as a TLD path error or timeout.


Mark.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Dave Lawrence]

Tony Finch writes:
> > So, what are people's favorite tools, especially those that you can just
> > point a user at?
> 
> I wouldn't point a user at any of these unless I think they have a good
> amount of DNS expertise :-)

Indeed.  I recently had to field a complaint that invoked an analysis
by https://dnschecker.org/domain-health-checker.php as being related
to problems someone was seeing.  That report didn't show errors, but
of the eight warnings that it issued--and that the reporter thought
needed attention--they were either incorrect, irrelevant, inscrutable,
or simply wrong.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Tony Finch]

Warren Kumari  wrote:
>
> At the moment the main site that I'm recommending for this is IIS.SEs
> Zonemaster - https://zonemaster.iis.se/ and DNSViz.
>
> Zonemaster is really close, but I'd like a few other options as well.
> DNSViz is, of course, excellent for DNSSEC debugging, but it can be fairly
> confusing to less experienced people trying to debug non-DNSSEC issues.

There's also https://dnssec-analyzer.verisignlabs.com/ but it is also
mainly about DNSSEC.

(Worth noting that when you update a domain object in the RIPE database,
it uses Zonemaster to check that the new setup is cromulent.)

> So, what are people's favorite tools, especially those that you can just
> point a user at?

I wouldn't point a user at any of these unless I think they have a good
amount of DNS expertise :-)

In my work many of the difficult or time-consuming support issues are
related to domain registration rather than DNS, so I have Mixed Feelings
about the state of whois etc.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Bailey: Southwest becoming cyclonic, 5 to 7. Rough or very rough.
Showers. Good.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[A. Schulze]

Am 11.06.21 um 20:00 schrieb Warren Kumari:
> So, what are people's favorite tools, especially those that you can just 
> point a user at?

Warren,

you mention both important tools

- https://zonemaster.net
- https://dnsviz.net

Both are also good for automated self monitoring as they can be build and run 
locally.

Sometimes I use also the EDNS Compliance Tester
- https://ednscomp.isc.org

Andreas
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Warren Kumari]

On Tue, Jun 8, 2021 at 6:03 AM Mark Delany  wrote:

> On 07Jun21, Giovane C. M. Moura via dns-operations allegedly wrote:
>
> > FWIW, we did a study a couple of years ago [1] analyzing these
> > inconsistencies. We found 13 million second-level domains (out of 166M)
> > that were inconsistent [0] (table 1, data from 2019-10-16)
>
> Asking for a friend. Did you use a tool that is generally available to the
> average Joe
> such that they can test their own domains?
>
> The most common DNS support questions I get from small-time dns admins
> invariably revolve
> around discrepancies between delegation, name servers and hidden masters.
>

Related to this, does anyone have a list of good web based "DNS checkers"?
I *feel* like there used to be a number of good tools, but I managed to
throw away that set of bookmarks. There are still many "test your recursive
servers " pages, but I'm looking for something that tests
authoratives, and walks all possible paths, checks for v4 and v6, MTU, etc.

At the moment the main site that I'm recommending for this is IIS.SEs
Zonemaster - https://zonemaster.iis.se/ and DNSViz.

Zonemaster is really close, but I'd like a few other options as well.
DNSViz is, of course, excellent for DNSSEC debugging, but it can be fairly
confusing to less experienced people trying to debug non-DNSSEC issues.

So, what are people's favorite tools, especially those that you can just
point a user at?

W



>
> I use a home-grown command-line tool which sorta, kinda works, but it's
> rough. For
> example, here's what it says about apple.com:
>
> apple.com. Errors: 12
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:c.ns.apple.com./
> 204.19.119.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:c.ns.apple.com./
> 204.19.119.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:d.ns.apple.com./
> 204.26.57.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:d.ns.apple.com./
> 204.26.57.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name
> Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name
> Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name
> Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name
> Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:b.ns.apple.com./
> 17.253.207.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:b.ns.apple.com./
> 17.253.207.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:a.ns.apple.com./
> 17.253.200.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:a.ns.apple.com./
> 17.253.200.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>
> Which is a lot of verbosity to say the glue from a.gtld-servers.net (and
> presumably all
> other GTLD servers) lacks the ipv6 addresses for a.ns.apple.com and
> b.ns.apple.com yet
> they're present in the in-bailiwick name servers.
>
> This of course is a minor matter rather than a fault, but it does mean
> that the ipv6 name
> servers will get a vastly reduced set of queries compared to all other
> name servers. To my
> mind this is indicative of an oversight on the domain admin's front.
>
> I'll really like to upgrade to a clearer command-line tool which can be
> incorporated into
> a zone update work-flow so that my friends can immediately know when they
> have messed
> up.
>
> Does such a beast exist?
>
>
> Mark.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Paul Vixie]

Viktor Dukhovni wrote on 2021-06-10 12:04:
> On Thu, Jun 10, 2021 at 08:24:17AM +0200, Petr Špaček wrote:
> 
>> ...
> 
> I'm inclined to agree.  Given a time-machine, and perverse priorities to
> then use it to try to undo DNS "mistakes", I'd be inclined to try to
> make "NS" be authoritative on the parent side, just like DS, and
> deprecate child-side NS entirely.
> 
> Of course that would mean that signed parent zones would sign every
> delegation, no opt-out (another win IMHO, that is viable now, but
> would have a been a hard sell back in ~2010).

given the world as it is, where credibility rules and authority status
make the apex NS more authentic than the leaf NS, and in the absence of
a time machine, these flights of fancy aren't material. but it should
help explain why the ns-revalidation draft exists and says what it does.

in the actual timeline, apex NS is very often more complete and more
accurate than leaf NS, simply by virtue of being directly controllable
by the zone administrator. work has been started several times to "pull
up" the apex values to replace the leaf values, but we never finish it.

i know of many instances where the leaf NS is half out of date, and that
the apex NS if learned will be fully up to date. we don't need to study
the matter, but i do want everyone to know that anecdotes are available
to fit _any narrative_ on this topic.

vixie


-- 
Sent from Postbox

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Viktor Dukhovni]

On Thu, Jun 10, 2021 at 08:24:17AM +0200, Petr Špaček wrote:

> Personally, with all the experience we have in 2021, I find the historic 
> decision to put authoritative NS RRs to the child side to be a poor 
> choice, to the point of being indefensible.
> 
> As Anthony points out, the parent version of NS has to work anyway. It
> forces me to think a better course of action would be ignoring
> child-side NS instead of adding complex asynchronous code paths to
> validate child NS, which is not technically needed.

I'm inclined to agree.  Given a time-machine, and perverse priorities to
then use it to try to undo DNS "mistakes", I'd be inclined to try to
make "NS" be authoritative on the parent side, just like DS, and
deprecate child-side NS entirely.

Of course that would mean that signed parent zones would sign every
delegation, no opt-out (another win IMHO, that is viable now, but
would have a been a hard sell back in ~2010).

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Petr Špaček]

On 04. 06. 21 18:56, Paul Vixie wrote:

On Fri, Jun 04, 2021 at 12:22:10PM -0400, Anthony Lieuallen via dns-operations 
wrote:

This is a question of being parent- vs. child- centric.  The parents in the
DNS tree delegate correctly.  The fact that the children delegate
incorrectly can be a small or non-issue depending on resolver.


those NS RRs are authoritative at the apex of the child, but not at the leaf of
the parent. this means they have higher credibility, and also that they can be
DNSSEC signed and validated. credibility and validity _matter_.


Google Public DNS uses only parent delegations (
https://developers.devsite.corp.google.com/speed/public-dns/docs/troubleshooting/domains#delegation
).  Largely for issues like this: the child delegations can be wrong, but
for the domain to work at all, the parent delegations must be correct.


without broad and deep failure, the quality of apex NS names will never improve.


(Resolvers that choose to use child delegations will likely in this case
discover that these delegations are bogus, and be left with only the valid
delegations, from the parent.)


at which point they should return SERVFAIL. failure _matters_.



Personally, with all the experience we have in 2021, I find the historic 
decision to put authoritative NS RRs to the child side to be a poor 
choice, to the point of being indefensible.


As Anthony points out, the parent version of NS has to work anyway. It 
forces me to think a better course of action would be ignoring 
child-side NS instead of adding complex asynchronous code paths to 
validate child NS, which is not technically needed.


I mean - why waste resources on improving something which is not even 
needed?


(To be clear: This is my personal opinion, and I'm sure some of my 
colleagues at ISC will disagree violently.)


--
Petr Špaček

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Paul Vixie]

Benno Overeinder wrote on 2021-06-07 05:29:
> On 04/06/2021 18:22, Anthony Lieuallen via dns-operations wrote:
>> ...  Largely for issues like this: the child delegations can be wrong,
>> but for the domain to work at all, the parent delegations must be
>> correct.  (Resolvers that choose to use child delegations will likely
>> in this case discover that these delegations are bogus, and be left
>> with only the valid delegations, from the parent.)
> 
> Unbound prefers the child side name servers, but if they do not answer,
> tries to use the parent-side name servers.

that strikes me as something we should recommend for all implementors,
more or less in the style of the "resimprove" draft. it's not a protocol
change but it does improve system resiliency.

> A little more detail, Unbound would on first resolve use the parent side
> servers.  On the second resolve, Unbound has the child-side name server
> data, ...  Then tries to send packets to them, getting failure
> answers.  Then tries the parent-side names servers as fall back.

this likewise strikes me as recommendable behaviour, but the point made
up-thread about minimal responses deserves to be re-raised now: if you
do not receive an authority section with an NS RRset "on first resolve",
then how do you learn the apex name server names to be used "on second
resolve"?

vixie

-- 
Sent from Postbox

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Paul Wouters]

On Mon, 7 Jun 2021, Benno Overeinder wrote:

Unbound prefers the child side name servers, but if they do not answer, tries 
to use the parent-side name servers.


A little more detail, Unbound would on first resolve use the parent side 
servers.  On the second resolve, Unbound has the child-side name server data, 
and lookups ns1.example.com and gets an answer from the IANA example servers. 
Then tries to send packets to them, getting failure answers.  Then tries the 
parent-side names servers as fall back.


And then there is harden-referral-path=yes which does insist on checking
the NS RRset at the child at least for DNSSEC signed zones. It's been
enabled for as long as I can remember in fedora/centos/rhel.

Paul
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Raffaele Sommese]

On Tue, Jun 8, 2021 at 11:59 AM Mark Delany  wrote:
>
> On 07Jun21, Giovane C. M. Moura via dns-operations allegedly wrote:
>
> > FWIW, we did a study a couple of years ago [1] analyzing these
> > inconsistencies. We found 13 million second-level domains (out of 166M)
> > that were inconsistent [0] (table 1, data from 2019-10-16)
>
> Asking for a friend. Did you use a tool that is generally available to the 
> average Joe
> such that they can test their own domains?

To perform analysis for [1], we wrote custom data analysis code, but
it is just for data and zones that we collect in the OpenINTEL Project
[3].
Maybe https://zonemaster.net/ can help with that?
It offers the possibility of looking for consistency (and delegation
issues), and they should have an (opensource) CLI version.
Best,
Raffaele

[3] https://openintel.nl/

-- 

Raffaele Sommese
Mail:raffyso...@gmail.com
About me:https://about.me/r4ffy
Gpg Key:http://www.r4ffy.info/Openpgp.asc
GPG key ID: 0x830b1428cf91db2a on http://pgp.mit.edu:11371/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Mark Delany]

On 07Jun21, Giovane C. M. Moura via dns-operations allegedly wrote:

> FWIW, we did a study a couple of years ago [1] analyzing these
> inconsistencies. We found 13 million second-level domains (out of 166M)
> that were inconsistent [0] (table 1, data from 2019-10-16)

Asking for a friend. Did you use a tool that is generally available to the 
average Joe
such that they can test their own domains?

The most common DNS support questions I get from small-time dns admins 
invariably revolve
around discrepancies between delegation, name servers and hidden masters.

I use a home-grown command-line tool which sorta, kinda works, but it's rough. 
For
example, here's what it says about apple.com:

apple.com. Errors: 12
   IP a.ns.apple.com./2620:149:ae0::53 in Name 
Server:c.ns.apple.com./204.19.119.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name 
Server:c.ns.apple.com./204.19.119.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name 
Server:d.ns.apple.com./204.26.57.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name 
Server:d.ns.apple.com./204.26.57.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name 
Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name 
Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name 
Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name 
Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name 
Server:b.ns.apple.com./17.253.207.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name 
Server:b.ns.apple.com./17.253.207.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP b.ns.apple.com./2620:149:ae7::53 in Name 
Server:a.ns.apple.com./17.253.200.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30
   IP a.ns.apple.com./2620:149:ae0::53 in Name 
Server:a.ns.apple.com./17.253.200.1 but not in delegation ;; 
AUTHORITY/a.gtld-servers.net./192.5.6.30

Which is a lot of verbosity to say the glue from a.gtld-servers.net (and 
presumably all
other GTLD servers) lacks the ipv6 addresses for a.ns.apple.com and 
b.ns.apple.com yet
they're present in the in-bailiwick name servers.

This of course is a minor matter rather than a fault, but it does mean that the 
ipv6 name
servers will get a vastly reduced set of queries compared to all other name 
servers. To my
mind this is indicative of an oversight on the domain admin's front.

I'll really like to upgrade to a clearer command-line tool which can be 
incorporated into
a zone update work-flow so that my friends can immediately know when they have 
messed
up.

Does such a beast exist?


Mark.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Giovane C. M. Moura via dns-operations]

--- Begin Message ---


> This is a question of being parent- vs. child- centric.  The parents in
> the DNS tree delegate correctly.  

FWIW, we did a study a couple of years ago [1] analyzing these
inconsistencies. We found 13 million second-level domains (out of 166M)
that were inconsistent [0] (table 1, data from 2019-10-16)


> Indeed.  In our first QNAME minimisation implementation, we used NS
>queries to follow delegations.

We saw this also clearly on .nl and .nz when Google Public DNS  (GDNS)
turned on q-min: fig 3 in [1]. Out of sudden we start to see far more NS
queries from GDNS than the other types of records.

/giovane

[0]
https://www.sidnlabs.nl/downloads/53BNt9EPxZQOCHYjqWhYfR/7295d79a207afc79cab6309d40a15a76/When_parents_and_children_disagree_Diving_into_DNS_delegation_inconsistency.pdf

[1]
https://www.sidnlabs.nl/downloads/4O6kRGL3Un0HrT5TcrBwaG/c69d421eb252da5902f46c1605175649/Clouding_up_the_Internet_how_centralized_is_DNS_traffic_becoming.pdf
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Benno Overeinder]

On 05/06/2021 20:11, Paul Vixie wrote:

On Sat, Jun 05, 2021 at 05:05:54PM +0200, A. Schulze wrote:

... What are NS records good for, if for $reason no resolver implement step 3.5:

3.5  The resolver ask of the glue-NS for "house.xa." NS to get a authoritative
list of "house.xa." NS


i expect these NS RRs to become visible in any validating full resolver that
implements QNAME Minimization. that's not a protocol change.


Indeed.  In our first QNAME minimisation implementation, we used NS 
queries to follow delegations.  This worked 99% of the time (well, 
almost all, I can't put a number on it).  We found that there are 
middleboxes that clearly dropped NS queries.  So instead we used QTYPE 
A/ in QNAME minimisation to follow delegations.  With good results.



-- Benno

--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Benno Overeinder]

On 04/06/2021 18:22, Anthony Lieuallen via dns-operations wrote:
On Fri, Jun 4, 2021 at 11:58 AM A. Schulze > wrote:


So I wonder, why do so many resolver [1] obviously do only follow a
delegation and ignore authoritative data?


This is a question of being parent- vs. child- centric.  The parents in 
the DNS tree delegate correctly.  The fact that the children delegate 
incorrectly can be a small or non-issue depending on resolver.  Google 
Public DNS uses only parent delegations ( 
https://developers.devsite.corp.google.com/speed/public-dns/docs/troubleshooting/domains#delegation 
 
).  Largely for issues like this: the child delegations can be wrong, 
but for the domain to work at all, the parent delegations must be 
correct.  (Resolvers that choose to use child delegations will likely in 
this case discover that these delegations are bogus, and be left with 
only the valid delegations, from the parent.)


Unbound prefers the child side name servers, but if they do not answer, 
tries to use the parent-side name servers.


A little more detail, Unbound would on first resolve use the parent side 
servers.  On the second resolve, Unbound has the child-side name server 
data, and lookups ns1.example.com and gets an answer from the IANA 
example servers.  Then tries to send packets to them, getting failure 
answers.  Then tries the parent-side names servers as fall back.


-- Benno

--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Paul Vixie]

On Sat, Jun 05, 2021 at 04:11:43PM -0400, Viktor Dukhovni wrote:
> On Sat, Jun 05, 2021 at 06:11:06PM +, Paul Vixie wrote:
> > I expect these NS RRs to become visible in any validating full resolver that
> > implements QNAME Minimization. that's not a protocol change.
> 
> That does not always work, and may work even less often in the future,
> because:
> 
> * If the query is at the zone apex (e.g. gmail.com MX lookup), then 
>   no NS query is issued at the final zone cut, since it is also the
>   final qname, and the RRtype is then from the actual question.
> 
> * Once 7816bis is published and adopted (last call at the moment),
>   the queries used for qname minimisation will typically be "A",
>   rather than "NS".

ah. so we're back to ns-revalidate. thanks for clarifying this for me.

ns-revalidate is also not a protocol change.

"data which is not used will be wrong," according to kenneth orr, in
_structured systems development_ (1977). this condition is self-sustaining,
as we see from "parent-centric dns resolution". this logic motivates itself
by the fact that apex NS RRs are often wrong, and by avoiding the apex NS,
amplifies the likelihood that apex NS RRsets will be wrong. self-fulfilling.

we need to always-use the apex NS, and let failures occur. perhaps this
ought to be done in the modern "A/B testing" so that only some fraction of
resolutions will treat the apex NS as being of higher credibility (by being
authoritative, and subject to DNSSEC validation), so that zones whose apex
NS is wrong will have worse service overall but won't fail outright.

but "parent-centric" is bad for the hygiene, health, and future of DNS --
and this cannot be a rational choice even if it is good for the operators of
resolvers who emit SERVFAIL less often thereby. every choice we make is a
vote for one future over another.

-- 
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Viktor Dukhovni]

On Sat, Jun 05, 2021 at 06:11:06PM +, Paul Vixie wrote:

> On Sat, Jun 05, 2021 at 05:05:54PM +0200, A. Schulze wrote:
> > ... What are NS records good for, if for $reason no resolver implement step 
> > 3.5:
> > 
> > 3.5  The resolver ask of the glue-NS for "house.xa." NS to get a 
> > authoritative
> > list of "house.xa." NS
> 
> I expect these NS RRs to become visible in any validating full resolver that
> implements QNAME Minimization. that's not a protocol change.

That does not always work, and may work even less often in the future,
because:

* If the query is at the zone apex (e.g. gmail.com MX lookup), then 
  no NS query is issued at the final zone cut, since it is also the
  final qname, and the RRtype is then from the actual question.

* Once 7816bis is published and adopted (last call at the moment),
  the queries used for qname minimisation will typically be "A",
  rather than "NS".

-- 
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Paul Vixie]

On Sat, Jun 05, 2021 at 05:05:54PM +0200, A. Schulze wrote:
> ... What are NS records good for, if for $reason no resolver implement step 
> 3.5:
> 
> 3.5  The resolver ask of the glue-NS for "house.xa." NS to get a authoritative
> list of "house.xa." NS

i expect these NS RRs to become visible in any validating full resolver that
implements QNAME Minimization. that's not a protocol change.

-- 
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[John Levine]

According to A. Schulze :
>Hello,
>
>we found the domain "xn--80atcidr8i.xn--p1ai." in one of our logs.
>
>the TLD "xn--p1ai." delegate "xn--80atcidr8i.xn--p1ai." to two working 
>nameservers.
>But these nameserver choose to announce "ns1.example.com" and 
>"ns2.example.com" as authoritative.
>These names are garbage.
>
>But most resolver do not fail to give an answer for "xn--80atcidr8i.xn--p1ai. 
>/A"
>So I wonder, why do so many resolver [1] obviously do only follow a delegation 
>and ignore authoritative data?
>Is it really some sort of "Hey, you asked for $domain/A, the setup is so 
>broken, but I tried really my best: here as an answer..." ?

For better or worse, DNSSEC validates the data itself, not the path
you took to get there. I have a local root which gets its info from
some servers at ICANN, not any of the regular root servers, but since
the DNSSEC signatures are OK, I don't care.

Parent and child NS have been out of sync as long as there have been
NS, and I have seen no pattern about which is more likely to be
"correct". If the server has the data and the signatures are good, why
do you care where it came from? And if it's not signed, the zone owner
apparently doesn't care either.

I realize that with DoH and DoT we are edging toward path validation, but I'd 
prefer to leave those
worms in the can for the moment.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[A. Schulze]

Am 05.06.21 um 14:56 schrieb Mats Dufberg:
> 3. The .xa NS returns a referral to the NS of house.xa.
> 4. The resolver send a request for "www.house.xa. A" to an house.xa NS.
> 
> To force the use of NS from the zone the DNS protocal has to be rewritten, 
> and if that is done, why not remove the NS from the zone and make them 
> authoritative records of the parent?

That's a good question. What are NS records good for, if for $reason no 
resolver implement step 3.5:

3.5  The resolver ask of the glue-NS for "house.xa." NS to get a authoritative 
list of "house.xa." NS

Andreas
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Vladimír Čunát]

On 05/06/2021 13.11, A. Schulze wrote:

Is "being client centric" a candidate for a "dns-flag-day-2022"?
Consider .com like to intercept gmail.com. Changing the delegation in .com 
would be enough. Really?


The parent has full control of its subtree anyway.  They can even roll 
the DNSSEC key of the child to anything.  Getting a TLS cert for "big 
names" will be hard without causing alarm, though (e.g. cert. 
transparency)... and you'd surely need that to intercept e-mail towards 
an end-client.


Recent discussion threads I see as related were around these two proposals:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-00.txt
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only

--Vladimir

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Mats Dufberg]

If the servers of the daughter zone returns minimal answer, which is legal, 
then the resolver will not even see the NS records of the zone.

1. The resolver get a request for "www.house.xa. A" and has the NS incl. IP 
addresses for xa.
2. The resolver sends a request for "www.house.xa. A" to an .xa NS.
3. The .xa NS returns a referral to the NS of house.xa.
4. The resolver send a request for "www.house.xa. A" to an house.xa NS.
5. The house.xa NS returns a minimal answer with "www.house.xa. A 192.0.2.50" 
in the answer section and no other DNS recorcs.

To force the use of NS from the zone the DNS protocal has to be rewritten, and 
if that is done, why not remove the NS from the zone and make them 
authoritative records of the parent?


Mats

-- 

---
Mats Dufberg
mats.dufb...@internetstiftelsen.se
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/
 

On 05/06/2021, 13:44, "dns-operations on behalf of A. Schulze" 
 wrote:



Am 04.06.21 um 17:52 schrieb A. Schulze:

> So I wonder, why do so many resolver [1] obviously do only follow a 
delegation and ignore authoritative data?

Is "being client centric" a candidate for a "dns-flag-day-2022"?
Consider .com like to intercept gmail.com. Changing the delegation in .com 
would be enough. Really?

Andreas

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[A. Schulze]

Am 04.06.21 um 17:52 schrieb A. Schulze:

> So I wonder, why do so many resolver [1] obviously do only follow a 
> delegation and ignore authoritative data?

Is "being client centric" a candidate for a "dns-flag-day-2022"?
Consider .com like to intercept gmail.com. Changing the delegation in .com 
would be enough. Really?

Andreas

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Paul Vixie]

On Fri, Jun 04, 2021 at 12:22:10PM -0400, Anthony Lieuallen via dns-operations 
wrote:
> This is a question of being parent- vs. child- centric.  The parents in the
> DNS tree delegate correctly.  The fact that the children delegate
> incorrectly can be a small or non-issue depending on resolver.

those NS RRs are authoritative at the apex of the child, but not at the leaf of
the parent. this means they have higher credibility, and also that they can be
DNSSEC signed and validated. credibility and validity _matter_.

> Google Public DNS uses only parent delegations (
> https://developers.devsite.corp.google.com/speed/public-dns/docs/troubleshooting/domains#delegation
> ).  Largely for issues like this: the child delegations can be wrong, but
> for the domain to work at all, the parent delegations must be correct.

without broad and deep failure, the quality of apex NS names will never improve.

> (Resolvers that choose to use child delegations will likely in this case
> discover that these delegations are bogus, and be left with only the valid
> delegations, from the parent.)

at which point they should return SERVFAIL. failure _matters_.

-- 
Paul Vixie
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Anthony Lieuallen via dns-operations]

--- Begin Message ---
On Fri, Jun 4, 2021 at 11:58 AM A. Schulze  wrote:

> So I wonder, why do so many resolver [1] obviously do only follow a
> delegation and ignore authoritative data?
>

This is a question of being parent- vs. child- centric.  The parents in the
DNS tree delegate correctly.  The fact that the children delegate
incorrectly can be a small or non-issue depending on resolver.  Google
Public DNS uses only parent delegations (
https://developers.devsite.corp.google.com/speed/public-dns/docs/troubleshooting/domains#delegation
).  Largely for issues like this: the child delegations can be wrong, but
for the domain to work at all, the parent delegations must be correct.
(Resolvers that choose to use child delegations will likely in this case
discover that these delegations are bogus, and be left with only the valid
delegations, from the parent.)
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] why does that domain resolve?

[A. Schulze]

Hello,

we found the domain "xn--80atcidr8i.xn--p1ai." in one of our logs.

the TLD "xn--p1ai." delegate "xn--80atcidr8i.xn--p1ai." to two working 
nameservers.
But these nameserver choose to announce "ns1.example.com" and "ns2.example.com" 
as authoritative.
These names are garbage.

But most resolver do not fail to give an answer for "xn--80atcidr8i.xn--p1ai. 
/A"
So I wonder, why do so many resolver [1] obviously do only follow a delegation 
and ignore authoritative data?
Is it really some sort of "Hey, you asked for $domain/A, the setup is so 
broken, but I tried really my best: here as an answer..." ?

Andreas

[1]
 - 1.1.1.1
 - 8.8.8.8
 - 9.9.9.9
 - unbound-1.13.1
 - Debian Buster's Bind 9.10.3
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations