Dan McCombs via dns-operations writes:
> Ah, yes, so in this case the addresses given back when no edns
> subnet is provided are the addresses of servers in eu-west, whereas
> with the resolver's own IP (or /24 subnet, or the subnet of clients
> querying it) as the edns subnet gets more expected
Peter DeVries via dns-operations writes:
> Another relevant draft:
> https://datatracker.ietf.org/doc/html/rfc8906
>
> Not sure how, it doesn't address _. as a use case at all and I only
> see testing for minimal EDNS not minimal qname.
The journey of that document was with, essentially,
Peter DeVries via dns-operations writes:
> We almost blocked these because we didn't know what they were but then
> I stumbled upon one of the old RFC drafts for query minimization and
> it does mention this as a technique.
Why would you drop them if you had not stumbled on the old draft?
It is
Puneet Sood writes:
> Jaap up-thread used fpdns to figure out the first question.
> fingerprint (e.ns.email.sonyentertainmentnetwork.com, 207.251.96.133): DJ
> Bernstein TinyDNS 1.05 [Old Rules]
Subtle correction: to figure out one possible answer to the first question.
Greg Choules via dns-operations writes:
> I am including in this mail the RNAME from the SOA (same for both
> zones) in the hope that someone who is responsible for DNS at Sony
> entertainment will see this and take note.
And tell us what in the world DNS software they're running, and why
they
--- Begin Message ---
Vix said:
> https://www.icann.org/en/system/files/files/sac-053-en.pdf
Yep, thanks for bringing it up. Genuinely appreciated.
I'm aware "SSAC also recommends that the use of DNS resource records
such as A, , and MX in the apex of a TopLevel Domain (TLD) be
Viktor Dukhovni writes:
> Single label names passed to getaddrinfo(3) should not result in single
> label "A" or "" DNS queries.
http://ai./
Admittedly a rarity, and in general problematic in other contexts. My
own corporate VPN won't even allow a proper DNS lookup of it (or any
address
Dave Lawrence via dns-operations writes:
> I accept that the only way to really capture
> all of these queries into the global DNS is via a delegation,
Brian Dickson reminded me of his CNAME proposal earlier in the thread,
and I think that is also an approach worth further investi
--- Begin Message ---
Vladimír Čunát writes:
> If the root zone is unchanged, many names could be hidden before
> reaching root servers - by DNSSEC aggressive caching and/or various
> local-root variants. (I'm not sure if we can well measure the extent to
> which this happens.)
That's an
John R Levine writes:
> Unfortunately, now we've circled back to where we started. Remember that
> the NC in NCAP stands for Name Collision, and the whole point of the
> project is to figure out how risky it is to add familiar looking new
> names.
I seem to be exceptionally derpy right now,
Michael Sinatra writes:
> I was dead in the water with slack, and upon issuing an 'rndc flush
> slack.com' to my home DNS resolver, and then doing same to $dayjob (for
> those using our VPN), everything cleared up. I'll let everyone here
> draw inferences.
No inferences needed; that was the
Shreyas Zare writes:
> And all of the 3 CNAME records are within the zone cut for the
> received SOA. To make the resolver work with this issue, the
> negative cache implementation had to be removed for CNAMEs with
> NXDOMAIN case.
To be clear, and this could well be something that community was
Viktor Dukhovni writes:
> Well, in this particular case queryes with rtype DS for "cfe.uber.com"
> do get NXDOMAIN, while queries of type NS do not.
Ooh my bad. Yeah, that's hard broken. I can guess at the code
path that is causing this set of symptoms, and expect that at least
that until
Paul Vixie writes:
> On Sun, Aug 08, 2021 at 03:20:24PM +0530, Shreyas Zare wrote:
> > ... The resolver I have does restart for the last CNAME regardless
> > of the RCODE but, the negative cache implementation based on RFC2308 and
> > RFC8020 caused the NXDOMAIN response to get cached causing the
I agree with Viktor that the parent should have delegation records for
the same-server child, but note that response with the rcode NXDOMAIN
for a CNAME chain shouldn't be causing a problem for a modern
resolver. A resolver should restart query processing with the target
of each CNAME in the
Stephane Bortzmeyer writes:
> Clearly Akamai Edge. They acknowledged it on their status site "a
> software configuration update triggered a bug in the DNS system, the
> system that directs browsers to websites. This caused a disruption
> impacting availability of some customer websites."
When we
Klaus Darilion writes:
> Are there any tools (bash, php ...) which accepts single
> RRSIG RR and single DNSKEY RR and does the validation?
dnsviz can be run on the command line for pre-delegation testing,
using staged DNSSEC data as necessary.
https://github.com/dnsviz/dnsviz
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
Our friend and colleague Dan Kaminsky has passed away of complications
from diabetes. He was the discoverer/inventor of the DNS
vulnerability that came to bear his name, the ability to take over
whole swaths of domains much more easily than had previously been
thought possible.
Announcement
Paul Vixie writes:
> do you know for a fact that someone who argued the GDPR case was in
> fact carrying water for verisign?
No, I don't. To be clear that is not what I was asserting. "Carrying
water" has a derogatory connotation that has never been in my mind
about this whole thing, either
To me, Andrew's retelling of the facts but for the emphasis.
There's stated reasons, then there's the motivating reasons. GDPR was
useful in making the argument, but Verisign and the pain of .com were
the real motivation.
___
dns-operations mailing list
A few recent analyses I've done at DNSViz have had warnings like
these:
com/DS (alg 8, id 30909): The server appears to support DNS
cookies but did not return a COOKIE option. (192.5.5.241,
UDP_-_EDNS0_4096_D_KN)
Now I realize that F-Root is a large, heterogeneous set. Any idea
which
I'm not really following your logic, Andrew (or Mark), for how
applying IDNA rules is relevant to interpreting the labels in
question.
Yes, I read your cited text from RFC 5890, but still am not grokking
how it is relevant for dig choking on -.house.gov just because IDN
output is enabled. It
Paul Hoffman writes:
> I started this thread with:
>dig +dnssec +noidnout anynameyouwant.house.gov a
> Try that without the +noidnout option.
Interesting. FWIW at first I saw no problem, because my MacBook has
an older version of dig in /usr/bin. On my server with 9.16.10,
though, the
Paul Hoffman writes:
> I am using tools that expect host names instead of domain names (in
> this case, dig);
I think I must be misunderstanding something, or at least haven't
imagined widely enough the possibilities of your meaning here. dig
has a particular expectation for hostnames either
Peter van Dijk writes:
> Apparently the trailing dot "thing" never hits the wire?
> That is correct. The DNS protocol has no concept of a trailing dot being
> present or not.
Or to put it another way, language is tricky and I'd say that DNS on
the wire always has a trailing dot and has no
Stephane Bortzmeyer writes:
> P Vixie wrote
> > you know that the plural of anecdote isn't data:
>
> I recently discovered this english word and I love it:
> https://en.wiktionary.org/wiki/anecdata
And one link more of relevance:
Kim Davies writes:
> Nothing in this proposal prejudices changes to how the KSK for the
> "arpa" zone may evolve in the future. I would suggest any effort
> to define new baseline requirements for the "arpa" KSK be handled
> separately as they are distinct from the objective of this draft. The
>
Viktor Dukhovni writes:
> Interesting. I would have expected the RDATA to just be opaque bytes
> when stored, and the server to return what ever it had, e.g.:
>
> _25._tcp.smtp.example.com. IN TLSA #2 0001
> _25._tcp.smtp.example.com. IN RRSIG TLSA ...
>
> and let the client deal with
Brian Somers writes:
> Heh, mail.protection.outlook.com has consumed many hours of my time
> in the past month :(
The actual MTA itself is a bit vexsome, as well. I've had a message
stuck in queue for several days now because "lost connection ... while
sending message body".
Even thought the
Calvin Browne writes:
> does anyone here know how 8.8.8.8 handles recursive glueless situations?
The Google folks are on the list and undoubtedly will answer, but I'm
still curious about what even prompts the question.
If it's actually missing glue -- NS records that are under the
delegation
Ángel writes:
> I have seen the opposite problem than the op, servers returning NXDOMAIN
> when there are actually child records, and they should have returned
> NODATA, such as querying _domainkeys.
Right, this is absolutely a problem too, with the practical
consequence that it thwarts qname
Wesley Peng writes:
> My question is about their implementation.
> Does it mean any domain ending with .idk went to an interface, this
> interface queried the domain part before .idk from wikipedia, then
> returned a URL redirection to some other website?
Pretty much yes. They take the page
Matthew Richardson writes:
> However, is this going to cause any practical problems?
Even outside DNSSEC, where it absolutely would be a problem, there are
some context for specialty applications where the difference between
the two types of negative answers is meaningful. The examples I can
Denesh wrote:
>> Interestingly enough, the Super 7 - part of the IAO - who ensured
>> web addresses were real... were the main topic in the episode Ill
>> Tidings of Sherlock inspired US TV show Elementary .. I think it was
>> around 4 years ago.
I'm surprised I never heard of it at the time.
Grant Taylor via dns-operations writes:
> I fail to see how any government would prevent the necessary parties
> from attending if / when they fully understand the need. Especially
> when some of said governments have directives ~> mandates for use of DNSSEC.
It could turn into a real-life
Who from the community is at eNom these days? Looking for a higher
level operations contact. Thanks.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Florian Weimer writes:
> How would a DoH client know that the recursive resolver is “forbidden
> to forward” ECS data?
It doesn't know clearly. All it knows is that if it gets REFUSED when
it sends a prefix outside its own address space, then something was
wrong. If that then succeeds it can
Paul Ebersman writes:
> mallman> I wonder if we're ever allowed to just decide this sort of
> mallman> thing is ridiculous old shit and for lots of reasons we can and
> mallman> should just garbage collect it away.
>
> We aren't allowed as IETF/engineers. The world sort of is. ;)
I see the :)
Mehmet Akcin writes:
> 5/3/2020 (March)
Because National Absinthe Day?
... National Cheese Doodle Day?
... National Multiple Personality Day?
(All true; ref: http://www.holidays-and-observances.com/march-5.html)
Or maybe it's a historical reference? The Boston Massacre?
Viktor Dukhovni writes:
> We can't have both of:
>
>* It is valid to return non-authoritative cached data for RD=0
>* It is invalid to return AA=0 in response to RD=0 requests.
>
> Which shall it be? You say you find the first useful, but then you
> really can't have the second, the
Paul Vixie writes:
> so, answering REFUSED when authoritative-only and receiving RD=1, and
> answering REFUSED when recursive-only and receiving RD=0, and treating
> AA=0 as "lame" when doing recursion, all lead to a choppy present but a
> smoother future.
The third one seems distinctly
Viktor Dukhovni writes:
> Yes, the expected behaviour when you explicitly request a CNAME
> record is that (modulo DNAMEs in some parent zone) the qname is
> resolved without further indirection, returning a CNAME if present
> there, NXDOMAIN if the qname does not exist, or else NODATA.
Spot on.
43 matches
Mail list logo
