* Daisuke HIGASHI:
> draft-fujiwara-dnsop-fragment-attack-01:
>
>> 3. Current status
>>
>> [Brandt2018] showed that Linux version 3.13 and older versions are
>> vulnerable to crafted ICMP fragmentation needed and DF set packet and
>> off-path attackers can set some of authoritative servers'
* Tim Wicinski:
> For the ZONEMD RR Type, where in the registry do the authors think it
> should go? While some of that falls on the Expert Review process, I think
> the document authors should capture their rationale in the document. If
> the proposed RR Type is greater than 256 (which I think
* John R. Levine:
> On Sat, 28 Jul 2018, Florian Weimer wrote:
>> A malicious server might never stop sending data, or claim that the
>> transfer is ridiculously large. If the zone digest does not include
>> information about the amount of data, this can only be detecte
* Paul Wouters:
> Another reason for an rr count number in the rrtype.
The typical RR size is perhaps 1/300 of the protocol maximum (much
less without DNSSEC), so this is only sufficient for small zones.
___
DNSOP mailing list
DNSOP@ietf.org
https://w
* John R. Levine:
that the served zone is too large. Otherwise, the receiver has to
download the entire zone before it can determine that the hash does
not match. ...
>
>> On the other hand, clients will likely have a pretty good idea for the
>> size of the zone, so they could tran
* John Levine:
> In article <87h8kp7sqf@mid.deneb.enyo.de> you write:
>>The ZONEMD record should contain a size indicator for the zone,
>>something that allows a receiver to stop downloading if it is clear
>>that the served zone is too large. Otherwise, the receiver has to
>>download the enti
* Duane Wessels:
> I wouldn't be opposed to this in principle -- say an RR count field.
That doesn't really bound the amount of transferred data, I think,
because RR size can still vary widely. I believe something that
counts the hashed bytes would be more helpful and about as easy to
implemen
The ZONEMD record should contain a size indicator for the zone,
something that allows a receiver to stop downloading if it is clear
that the served zone is too large. Otherwise, the receiver has to
download the entire zone before it can determine that the hash does
not match.
* Paul Vixie:
> in other words we should re-order rrsets by default, so that very few
> people or agents are ever prone to think their order is stable. the spec
> says they are unordered, but human nature says, expect more of what
> you're seeing.
But the client has to sort them again based on
On 06/15/2018 05:45 PM, Erik Nygren wrote:
I suspect starting assumptions are roughly in the range of:
* Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of
round-robin in RRset responses.
* There are a variety of ways to implement round-robin (randomize,
permute, etc).
* Server
On 04/13/2018 04:47 PM, bert hubert wrote:
2) Try:
ping goes-via-embedded-nul.tdns.powerdns.org
ping goes-via-embedded-space.tdns.powerdns.org.
ping goes-via-embedded-dot.tdns.powerdns.org.
None of these resolve when I try them, I wonder if that is because
implementations want CNA
On 11/28/2017 08:50 PM, Andrew Sullivan wrote:
That leaves the task of the referrals definition. I have some new
text below:
---%<---cut here---
Referral: A type of response in which a server, signalling that it is
not authoritative for an answer, provides the querying resolver with
an alterna
On 09/21/2017 06:50 AM, Paul Vixie wrote:
both ideas are wrong. what we have to do is arrange to fragment, using
the ipv6 extension header, all ipv6 udp, for a period of not less than
five years. noone who blocks ipv6 extension headers should be able to
get reliable ipv6 udp services. we have t
On 04/21/2017 05:08 PM, Bob Harold wrote:
I can understand you wanting a "getfqdn" function to return the FQDN (fully
qualified domain name) without doing canonicalization.
But just so we are clear on the DNS terms,
"access.redhat.com" and "access.redhat.com.edgekey.net" are "aliases"
"e133.b.a
On 04/27/2017 11:31 AM, Mark Andrews wrote:
If you want to advocate for changes to behaviour that is fine, but
advocate for that. Just saying "shouldn't the rcode be NOERROR"
isn't doing that. Then there is DNSSEC. If the target zone is
signed and DO=1 is set in the query should you include th
On 04/20/2017 08:36 AM, Evan Hunt wrote:
On Wed, Apr 19, 2017 at 10:47:24PM -0400, Paul Wouters wrote:
ANAME could just be a regular RRTYPE without any special handling,
meaning "go look there for up to date information on A/". It could
come along A/ records using one of the existing bit
On 04/11/2017 10:47 PM, Evan Hunt wrote:
On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote:
And in order to accommodate them, we upgrade the DNS server
infrastructure across the Internet?
Them, and web browser implementers who just don't want to use SRV.
SRV wouldn&#
On 04/11/2017 10:16 PM, Evan Hunt wrote:
On Tue, Apr 11, 2017 at 09:11:54PM +0200, Florian Weimer wrote:
I don't see how you can detect loops without DNS protocol changes. The
query that comes back will look like a completely fresh query.
We can put a limit on the number of hops tha
On 04/11/2017 10:15 PM, Tony Finch wrote:
On 11 Apr 2017, at 20:39, Florian Weimer wrote:
On 04/11/2017 09:15 PM, Tony Finch wrote:
That doesn't work if the web server is at 3rd party provider A but you want
provider B's mail service not provider A's.
I don't und
On 04/11/2017 09:15 PM, Tony Finch wrote:
On 11 Apr 2017, at 20:09, Florian Weimer wrote:
On 04/11/2017 08:42 PM, Tony Finch wrote:
If you have a subdomain that needs to be a mail domain and a web site, you
need an MX pointing at your mail server and address records pointing at
your web
On 04/10/2017 12:04 PM, Peter van Dijk wrote:
Section 3 is currently written in such a way that a recursive DNS
lookup must be performed at the authoritative server side. I don't
think it is necessary to require that. A recursive DNS lookup of the
target is just one way to implement this.
Wh
On 04/11/2017 08:42 PM, Tony Finch wrote:
Paul Wouters wrote:
Can you give me an example of deploying ANAME outside the zone APEX that
is not solved by allowing a CNAME to point to a CNAME (which most code I
think already allows anyway)
https://www.ietf.org/mail-archive/web/dnsop/current/msg
On 04/11/2017 05:45 PM, Tony Finch wrote:
Florian Weimer wrote:
I think the introduction should discuss why it is not possible to push the
CNAME to the parent zone, replacing the entire zone with an alias.
You can't replace an entire zone with a CNAME if it has subdomains. ANAME
record
On 04/07/2017 08:11 PM, Evan Hunt wrote:
Title: Address-specific DNS Name Redirection (ANAME)
I think the introduction should discuss why it is not possible to push
the CNAME to the parent zone, replacing the entire zone with an alias.
Section 3 is currently written in such a way th
* Mark Andrews:
> In message <87bmz3p4lt@mid.deneb.enyo.de>, Florian Weimer writes:
>> * Robert Edmonds:
>>
>> > I think there was already a thread on this topic recently on this list
>> > ("Order of CNAME and A in Authoritative Reply" from
* Robert Edmonds:
> I think there was already a thread on this topic recently on this list
> ("Order of CNAME and A in Authoritative Reply" from August 2015). There
> was some discussion over "adding" versus "appending" and it was pointed
> out that a lot of existing code (e.g., the BSD stub resol
On 03/23/2016 09:03 PM, Andrew Sullivan wrote:
> I don't understand how it's a way to evaluate this claim. DNSSEC
> includes a bit (DO) that says you're prepared to handle the additional
> data in the answer section. Indeed, the unpreparedness of people for
> this data was just exactly the reason
On 03/22/2016 12:45 AM, Marek Vavruša wrote:
> there was an interest in reducing latency for address record lookups.
> Me and Olafur wrote a draft on adding records to A answers and
> treating them as authoritative. This fixes latency issues with NS
> A/ discovery in resolvers and improve
On 03/22/2016 01:15 AM, Paul Vixie wrote:
>
>
> Marek Vavruša wrote:
>> ...
>>
>> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop--for-free/
>
> +1. we ought to have done this from the get-go.
It did not work back then because unexpected RRsets in the answer broke
resolvers. This is h
specially* during an unscheduled security update. If you were running
BIND 9.3 before, you are essentially running it afterwards as well.
--
Florian Weimer / Red Hat Product Security
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
* Stephane Bortzmeyer:
> On Wed, Jul 15, 2015 at 02:22:58PM -0700,
> Francisco Obispo wrote
> a message of 48 lines which said:
>
>> Well, even worse, what happens if decides
>> to create a new dns-like protocol that uses .foo, does that mean
>> that we should automatically block it?
>
> No n
* Tony Finch:
> What does 2 return to 3? It can't send a signed NSEC because DO=0.
ANY is special, you can get NSEC and RRSIG in responces with DO=0
(some implementations do that). With suitably aligned TTLs, I suppose
you can even end up with just a NSEC/RRSIG RRset pair.
NSEC3 is different be
* Evan Hunt:
> Last night the dumb-idea fairy visited me as I was falling asleep, and
> suggested that another way to reduce the impact of ANY queries would be
> to pick *one* rrset and return just that. (Probably the numerically
> smallest rrtype present at the node, plus RRSIGs if any.)
Yes, th
* Olafur Gudmundsson:
>> On Mar 18, 2015, at 11:55 AM, Paul Vixie wrote:
>>
>> we need a document that says "If you don't want to answer ANY,
>> here's how to do it interoperably." we don't need to say "you
>> should not answer ANY", but we do need to say "if you want to query
>> for ANY, here's
* Paul Vixie:
>> As a counterexample, RFC 6891 requires FORMERR responses without OPT
>> RRs from implementations which do not support EDNS:
>>
>>Responders that choose not to implement the protocol extensions
>>defined in this document MUST respond with a return code (RCODE) of
>>FORM
* W. C. A. Wijngaards:
> +1. Backwards compatibility means you cannot specify that existing
> implementations have to change.
Does it matter if they do not exist or are not considered practically
relevant?
As a counterexample, RFC 6891 requires FORMERR responses without OPT
RRs from implementat
r companies,
The reservation of “local” took more than a decade if I remember
correctly, and it did not benefit just Apple.
--
Florian Weimer / Red Hat Product Security
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
* Tim Wicinski:
> This starts a Call for Adoption for draft-ogud-dnsop-acl-metaqueries
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ogud-dnsop-acl-metaqueries/
No real comments on adoptions below, just some technical issues.
Is there are definition now what constitut
* Tony Finch:
>> Evan Hunt wrote:
>> >
>> > This could be a pretty brilliant solution, actually: If you're
>> > authoritative for a signed zone and you receive a query of type ANY,
>> > return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize
>> > a response containing a single R
* Evan Hunt:
> (It doesn't address qmail's problem, but that's a lost cause no
> matter which method is chosen.)
I think it does. qmail already copes correctly with a partially
cached ANY response (due to TTL mismatch between RRset), does it?
The new behavior just looks like a partially cached r
* Evan Hunt:
> On Thu, Mar 12, 2015 at 11:38:04PM +, Darcy Kevin (FCA) wrote:
>> So you're thinking it's more likely that we'll get folks to understand
>> this new type, that's designed to frustrate QTYPE=* queries in a
>> more-or-less graceful way, than it is to convince them to stop making
>
* Tony Finch:
> I also tried a stupid hack to send an ANY RR in the response. BIND's
> resolver treats this as a FORMERR and returns SERVFAIL to the client.
What about introducing a new non-meta RR type for this purpose? It
would not increase the response size by much.
_
* Olafur Gudmundsson:
> Title: Standard way for Authoratitive DNS servers to refuse ANY
NOTIMP doesn't do that, it tells resolvers to query another name
server for the zone. The authoriative server part of this proposal
increases the number of upstream ANY queries instead of reducing th
* Ted Lemon:
> On Mar 8, 2015, at 6:31 PM, Ralf Weber wrote:
>> I was told that the difference is that a security aware resolver does
>> not validate, but instead relies on the "Validating Stub Resolver" to
>> protect the user. So it would handle all the DNSSEC processing to the
>> authoritative
On 03/12/2015 11:36 AM, Jan Včelák wrote:
>> And does anyone actually use opt out with NSEC3?
>
> Yes, .com for example. My impression was that Opt-Out was the selling point
> of
> NSEC3, not the domain name hashing.
Okay. Are they interested in switching to NSEC5?
--
Fl
r less). Online
keys are less threatening than they used to be, and we aren't even
talking about long-term keys baked into software, but short/medium-term
keys which are easily replaced.
And does anyone actually use opt out with NSEC3?
--
Florian Weimer / Red Hat Product Security
kipped?
You really need to make this explicit.
> I agree that the description is insufficient. We will fix that.
Thanks.
--
Florian Weimer / Red Hat Product Security
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
FDH values.
As specified in the draft, the NSEC5 protocol still exposes the chain of
SHA-256 hashes of owner names. It does not offer better protection
against offline dictionary attacks than NSEC3.
Florian
--
Florian Weimer / Red Hat Product Security
___
DNS
* John Heidemann:
> DNS over TCP/53 is *already* persistent. No *protocol* changes are
> needed.
If you want to make the connections full-duplex instead of
half-duplex, you need to negotiate connection teardown at the DNS
layer. Otherwise, the TCP connection teardown will result in loss of
alre
* Mark Andrews:
> ENAME could be used immediately once the authoritative servers for
> the zone support it. It would just be insecure until validators
> catch up.
Uhm. Why insecure and not bogus?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf
* Mark Andrews:
> In message <87y50auqqf@mid.deneb.enyo.de>, Florian Weimer writes:
>> * Mark Andrews:
>>
>> >>>Another note is that the answer to the NS query, unlike the referral
>> >>>sent when the question is a full qn
* Mark Andrews:
>>>Another note is that the answer to the NS query, unlike the referral
>>>sent when the question is a full qname, is in the Answer section, not
>>>in the Authoritative section. It has probably no practical
>>>consequences.
>>
>> Most resolvers do not make NS quer
* Phillip Hallam-Baker:
>> If your ordinary resolver operator is a "carrier" is somewhat
>> questionable, but resolver operators generally comply with requests
>> for cleartext copies of traffic transitioning through their networks.
>>
>> I have no doubts that these operators will ask implementors
* Florian Weimer:
> There is another privacy-enhancing approach that is not mentioned in
> the draft: defensive delegations. For example, with current resolver
> behavior, the lack of a delegation for 1.E164.ARPA means that queries
> under that tree are sent to the E164.ARPA server
* Phillip Hallam-Baker:
> But first, cite actual legal authority because I don't believe your
> interpretation of the law is remotely correct.
§ 8 Abs. 3 TKÜV:
| Wenn der Verpflichtete die ihm zur Übermittlung anvertraute
| Telekommunikation netzseitig durch technische Maßnahmen gegen
| unbefugt
* Phillip Hallam-Baker:
> For a heavily trafficked resolver, the resolver-authoritative
> interaction can be addressed with caching and by pre-fetching the
> bulk of the requests. But this approach does not work so well for
> the lightly trafficked resolver and especially not a local resolver
> d
* Stephane Bortzmeyer:
> On Sat, Mar 08, 2014 at 06:07:48PM +0100,
> Florian Weimer wrote
> a message of 17 lines which said:
>
>> > It is. Section 2.2.2
>>
>> Can you quote it here?
>
> 2.2.2. In the authoritative name servers
Ahhh, this section he
* Stephane Bortzmeyer:
> On Sat, Mar 08, 2014 at 05:50:55PM +0100,
> Florian Weimer wrote
> a message of 22 lines which said:
>
>> The -sol draft mentions QNAME minimization without defining the
>> term.
>
> It is. Section 2.2.2
Can you quote it here? It s
* Stephane Bortzmeyer:
> I just posted a new version of the DNS privacy draft,
> draft-bortzmeyer-dnsop-dns-privacy-01. The most important difference
> is that it is now split in two, one pure problem statement,
> draft-bortzmeyer-dnsop-dns-privacy and an exploration of possible
> solutions, draft
* Stephane Bortzmeyer:
> I'm aware of draft-mohan-dns-query-xml, which partially solves my
> problem (except I would like the RDATA to be structured as well, not a
> blob of "hexadecimal data").
In this area, draft-levine-dnsextlang-00 might be helpful.
--
Florian We
re an API proposal somewhere? I can't see how this can
be implemented on top of the BSD sockets API, especially not with the
weak end system model.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsru
troducing sub-zones for the network
ranges which should receive longer TTLs.
In the non-DNSSEC case, you can simply return a SOA record whose owner
name is the full QNAME.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721
imilar fate? Then you might be right in the sense that the
IETF cannot set aside names for use at the protocol level.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-7
mary concern during the DURZ
phase.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
DNSOP mailing list
DNSOP@ie
me-grown pseudo-transport layers, and with SRV records, it is not
possible to figure out if HTTP is to be used or not.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-9
* Jim Reid:
> So what? If the served zones are signed, it simply doesn't matter if
> the address of a name server is spoofed or hijacked.
This is only true if the whole DNS tree is signed (and if you don't
value query privacy).
--
Florian Weimer
BFK edv
SASHA1 completely (in the
sense that you can register a crafted org domain name and get an RRSIG
from org that fits example.org as well, with private key material
known to you).
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +
appen with NSEC3 records
because their owner name does not normally match the queried name.
Therefore, NSEC3 records provide better insulation of child zones from
the DNSSEC deployment in the parent zone.
--
Florian Weimer
BFK edv-consulting GmbH
* Jim Reid:
> On 15 Jan 2010, at 13:20, Florian Weimer wrote:
>
>> DO is rather pointless because the priming response cannot be
>> validated anyway (even if ROOT-SERVERS.NET were secure, which is
>> currently not planned).
>
> It's not pointless. Validatin
5] Vanilla UDP (no EDNS0) if [4] fails
DO is rather pointless because the priming response cannot be
validated anyway (even if ROOT-SERVERS.NET were secure, which is
currently not planned).
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
n this at the DNS-OARC meeting last week:
>
> https://www.dns-oarc.net/files/workshop-200911/Duane_Wessels.pdf
Have you installed any trust anchors in the resolver? (I don't think
so, the packet numbers are a bit on the lower side for that.)
--
Florian Weimer
BFK ed
* Nicholas Weaver:
> Also, has someone done a study what the major recursive resolvers do
> on response failures from a root? Do they go to another first or do
> they try a smaller EDNS MTU?
Note that switching seems beneficial because six roots MTUs clearly
support MTUs less than 1500, and seve
* David Blacka:
> I actually researched this, and need to spend some time cleaning up
> the report before posting it to this list. But the bottom line is
> that yes, all responses save a few at the apex of root are below 1500b
> (actually, below 1100b). The responses that are larger are ". rrsig
* Alfred Hönes:
> There must be a hidden trick to introduce DNS Jumbograms we just
> forgot to mention
The claims about firewall issues seems dubious to me. It's certainly
not the 512 byte limit which is a problem here---I think we've got
pretty good empiric evidence that it's not a problem
* Matthew Dempsky:
> On Wed, Nov 4, 2009 at 11:26 AM, wrote:
>> The current deployment plan is to stage things to push out large
>> responses
>> early - prior to having any actual DNSSEC usable data ... ostensibly
>> to
>> flush out DNSmtu problems.
>
> Is this plan to pus
t: If I have got a client device (not DNS
proxy) which supports the proposed protocol, it will not work when I
connect it to a network which uses a resolver that performs this type
of spoofing, unless the spoofing resolver has specific support for
this protocol.
It's not "someone could do
* Alex Bligh:
> --On 21 October 2009 08:34:39 +0000 Florian Weimer wrote:
>
>>>> Mark, I din't think this is true given how the proposed protocol
>>>> works. For a start, you often cannot fetch the DNSKEY RR for ARPA
>>>> before running the proto
o exist in the public tree at all?
All we need is agreement from both ICANN and IETF that LOCAL.ARPA is
reserved and not to be delegated in the official tree.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76
* Mark Andrews:
> For LOCAL.ARPA to be accepted you need a break in the DNSSEC trust
> chain.
Mark, I din't think this is true given how the proposed protocol
works. For a start, you often cannot fetch the DNSKEY RR for ARPA
before running the protocol.
--
Florian Weimer
oned anyway".
ARPA will soon be signed, so I don't think this is much to worry
about. If the powers that be finally agree to make NXDOMAIN/NODATA
synthesis the default in the upcoming minor DNSSEC revision, this will
also help to cut down the number of requests.
--
Florian Weime
ort this protocol due to widespread DNS
poisoning.
I wholeheartedly support the creation of LOCAL.ARPA, though. But you
should mention that mDNS MUST NOT be used for LOCAL.ARPA (so that some
people don't get funny ideas).
--
Florian Weimer
BFK edv-consulting GmbH http
* Roy Arends:
> On Oct 7, 2009, at 8:57 AM, Florian Weimer wrote:
>
>> * Roy Arends:
>>
>>> At least for Nominet, I want (2) to do cross-checking, be able to
>>> check what things look like before they enter the pipeline,
>>> preferably
>>
publish button, its in
> the root, and world can check it with me, using dig.
Have you already got this self-service capability for non-DS changes?
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karls
istory service to get back on
| track. The trust history location is assumed available from the
| validator configuration. The validator then fetches old DNSKEY
| RRsets and checks they form a chain to the latest key.
Doesn't this defeat the purpose of key rollovers?
--
Florian Weimer
* Paul Vixie:
> since time is short, i would prefer a server-side change, supported by a
> spec change (which means this would head back to namedroppers@) whereby
> (bufsize<1220 && DO=1) would be treated as (DO=0).
And what does the resolver with a trust anchor do with the DO=0
answer? Requery
* JINMEI Tatuya / 神明達哉:
> What does a recursive server that implements the DNS redirect service
> do in this case?
Empty responses are typically rewritten. "NXDOMAIN redirect" is a
misnomer.
> then I guess authoritative server implementors who don't like
> NXDOMAIN redirect could introduce a "a
* Tony Finch:
> On Thu, 16 Jul 2009, Florian Weimer wrote:
>>
>> If you want to address the issue with hotspot doorway pages, you need
>> protocol changes.
>
> Better to use an intercepting proxy in that case, and for quarantining
> infected hosts.
Doesn't w
* Jason Livingood:
> Actual consumer behavior doesn¹t really seem to work that
> way, but I¹m not a behavioral psychologist. ;-) FWIW, I think most
> ISPs that introduce such services see around a 0.1% opt-out rate.
I would expect a higher rate of Dnschange/Zlob infections at a typical
* Tony Finch:
> On Thu, 16 Jul 2009, Florian Weimer wrote:
>>
>> (But I agree that a clean solution requires protocol development.)
>
> No, it just requires browser user interface improvements.
If you want to address the issue with hotspot doorway pages, you
* Paul Hoffman:
> Paul: that's over the top. Some of the services defined in the draft
> are highly desired by some Internet users.
Which ones?
Currently, when a user enters "mcrsoft" in the address bar, many
browsers will automatically send her to the Microsoft homepage. With
spoofed answers,
* Alan Barrett:
> I think that this sort of lying recursive resolver is a bad idea.
> Instead, I suggest a new "SUGGESTION" RR type that could be returned
> in the additional section of an error message. For example, if
> you ask for www.example.invalid, you could get back an NXDOMAIN
> error, wi
* Jelte Jansen:
> Ralf Weber wrote:
>>> No redirection on SERVFAIL seems to be a strange recommendation.
>>> Wouldn't this be a very good reason to provide a diagnostics page,
>>> especially if there's been a DNSSEC validation failure?
>> This sounds like an excellent idea to help DNSSEC adoption
* Ralf Weber:
> That really is an issue and could be addressed, there are a lot of
> case where a A record for a domain doesn't exists, but one for
> www.domain does exist.
True, and some browser have code to deal with this.
> Question then would be how that rewrite should be presented. As a
> n
* Jason Livingood:
> If anyone is interested and has time before IETF 75, I¹m happy to take
> feedback before then obviously.
Few players perform NXDOMAIN rewriting. Instead, ANCOUNT=0 rewriting
is used. This causes all kinds of problems, including redirections
for example.com when it hasn't go
* Stephane Bortzmeyer:
> Unless I'm wrong, the I-D about lying resolvers do not discuss the
> issue of zone cuts.
>
> If I type www.doesnotexistatall.com (the SLD does not exist and so I
> should get a NXDOMAIN), I get the IP address of the ad Web server. If
> I type .afnic.fr, I will get thi
vior
because the RFCs do not tightly specify it. There is very likely no
way to make zone changes in a way that pleases all resolvers. So most
operators don't even try to do it.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
de mitigation mechanisms are a
side effect of dealing with the unsigned referral/glue issue. After
all, if you've never validated the NS RRset and its addresses, a
registrar switch is indistinguishable from a previously unnoticed
attack based on a spoofed referral.
--
Florian Weimer
e it out of schedule, you might have
got some explaining to do. 8-)
Of course, this isn't a strong argument in favor of HSMs.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe
* Paul Vixie:
>> > As for "MX 0 ." the sooner this gets defined as no SMTP service for this
>> > domain the better. The cost for changing this is only every going to
>> > increase.
>>
>> It may take years before a significant portion of SMTP servers recognize
>> root domains as meaning no ser
> The MX RR will be ignored. There will be an DNS request and a
> fallback to the A RR for security.eu.debian.org. Newer versions of
> sendmail and Postfix will treat that MX RR as a bad MX and reject the
> message instead of retrying.
Exim also treats the record as a "no SMTP service here"
1 - 100 of 136 matches
Mail list logo
