Re: [Dnsmasq-discuss] DNSSEC on lookups of *.paypal.com no longer work
On 14/05/16 19:55, Uwe Schindler wrote: > Hi Simon, > >>> Well, that's the smoking gun. Dnsmasq is doing the right thing, and your >>> upstream server at 212.202.215.1 is broken. I realise that doesn't solve >>> the problem, but at least you know where to work now :) >>> >>> >>> (the reason dnsmasq is returning SERVFAIL is that there's a >>> chain-of-trust from the root that says paypal.com is signed, If the >>> answer to the paypal.com query isn't signed, it may be a false answer, >>> so it can't be trusted.) >> >> Of course this is the right thing to do! >> >> I will contact the upstream provider and ask them to fix this! >> >> Interestingly, two of their three IPv4 DNS servers have the problem. The 3rd >> one and all three IPv6 DNS servers are working fine. This explains why it >> sometimes worked. >> >> Maybe a good idea is: If a DNSSEC query fails and DNSMASQ knows more >> servers, retry on others, too? > > What do you think about this proposal? > The problem, is that there are many paths that cause DNSSEC validation to fail, and for most of the them, it's not obvious which query to retry and if that would help. In this case retrying the query would be possible, but in most cases, not. If a DNSSEC validation fails, there are many pieces of data that go into that validation, it's not possible to retry all of them and difficult to determine which answers are good and which bad. In the end, to do DNSSEC, you need upstream servers which provide the data. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Does dnsmasq support forwarding EDNS queries?
On 10/05/16 22:03, Jake Gold wrote: > Hello, > > I'm using dnsmasq as a local caching resolver and some of my queries result > in large answers (~1300 bytes) that are truncated without EDNS. > > When I query my local dnsmasq daemon: > > dig @localhost > > dig sends a query to dnsmasq using EDNS but dnsmasq forwards that query to > its upstream server without using EDNS. > > Is this just how dnsmasq works or is there a way to make dnsmasq forward > EDNS queries? (Or am I missing something?) > > Thanks in advance. > EDNS (in this context) is a way for the two ends of a DNS transaction to negotiate the maximum size of reply that can be sent over UDP. Dnsmasq will not strip an EDNS header from a query it forwards, but it might reduce the "maximum UDP size" field, based on the config setting --edns-packet-max. In the end, if an answer is too big, the query has to be re-done over TCP. A common problem with this is firewalls which block port 53 for TCP. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents
Great, thanks. I've applied your patch and made a further change:
instead of changing the filename behaviour based on CSA, it looks at the
filename provided. If it has a suffix (strictly, if it includes a '.'
character) then the filename is used as-is. Otherwise it as the layer
added as suffix.
That seems most sensible. It has a small risk of breaking existing
setups with files called boot.bios.0. but that can be handled with a
release-note in the changelog.
In git now.
Simon.
On 14/05/16 18:47, Michael Kuron wrote:
> I have included a patch below that makes essentially two modifications to get
> PXE working with the UEFI firmware in VMware.
> - It only appends the layer number to the file name on BIOS x86.
> - It always redirects the client to port 4011. To do that, only the siaddr is
> set and neither a boot file nor a PXE menu are included in the Offer sent
> upon receiving the Discover. In reaction to the ACK it then sends an ACK
> which includes either the single boot file name and server, or the PXE menu.
>
> This patch works to the same degree as my patch did. VMware boots fine with a
> single boot service, and the menu also works if you specify multiple, however
> you have to blindly navigate the menu because it is not shown on screen.
>
> Michael
>
>
> --- a/src/rfc2131.c
> +++ b/src/rfc2131.c
> @@ -63,7 +63,7 @@ static void pxe_misc(struct dhcp_packet *mess, unsigned
> char *end, unsigned char
> static int prune_vendor_opts(struct dhcp_netid *netid);
> static struct dhcp_opt *pxe_opts(int pxe_arch, struct dhcp_netid *netid,
> struct in_addr local, time_t now);
> struct dhcp_boot *find_boot(struct dhcp_netid *netid);
> -static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid,
> struct dhcp_packet *mess, struct in_addr local, time_t now);
> +static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid,
> struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe);
>
> size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int
> int_index,
> size_t sz, time_t now, int unicast_dest, int *is_inform, int
> pxe, struct in_addr fallback)
> @@ -824,7 +824,10 @@ size_t dhcp_reply(struct dhcp_context *context, char
> *iface_name, int int_index,
> else
> mess->siaddr = context->local;
>
> - snprintf((char *)mess->file, sizeof(mess->file), "%s.%d",
> service->basename, layer);
> + if (pxearch == 0)
> + snprintf((char *)mess->file, sizeof(mess->file), "%s.%d",
> service->basename, layer);
> + else
> + strncpy((char *)mess->file, service->basename,
> sizeof(mess->file));
> option_put(mess, end, OPTION_MESSAGE_TYPE, 1, DHCPACK);
> option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ,
> htonl(context->local.s_addr));
> pxe_misc(mess, end, uuid);
> @@ -879,11 +882,10 @@ size_t dhcp_reply(struct dhcp_context *context, char
> *iface_name, int int_index,
>
> clear_packet(mess, end);
>
> - /* Only do workaround for replies to 4011 */
> - if (!pxe)
> - mess->siaddr = tmp->local;
> - else
> - workaround = pxe_uefi_workaround(pxearch, tagif_netid,
> mess, tmp->local, now);
> + /* Redirect the client to port 4011 */
> + mess->siaddr = tmp->local;
> + /* Returns true if only one matching service is available. On
> port 4011, it also inserts the boot file and server name. */
> + workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess,
> tmp->local, now, pxe);
>
> if (!workaround && boot)
> {
> @@ -903,7 +905,7 @@ size_t dhcp_reply(struct dhcp_context *context, char
> *iface_name, int int_index,
> option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ,
> htonl(tmp->local.s_addr));
> pxe_misc(mess, end, uuid);
> prune_vendor_opts(tagif_netid);
> - if (!workaround)
> + if (pxe && !workaround)
> do_encap_opts(pxe_opts(pxearch, tagif_netid, tmp->local,
> now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end, 0);
>
> log_packet("PXE", NULL, emac, emac_len, iface_name, ignore ?
> "proxy-ignored" : "proxy", NULL, mess->xid);
> @@ -1989,7 +1991,7 @@ static int prune_vendor_opts(struct dhcp_netid *netid)
> and jamb the data direct into the DHCP file, siaddr and sname fields.
> Note that in this case, we have to assume that layer zero would be
> requested
> by the client PXE stack. */
> -static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid,
> struct dhcp_packet *mess, struct in_addr local, time_t now)
> +static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid,
> struct dhcp_packet *mess, struct in_addr local, time_t now, int pxe)
> {
Re: [Dnsmasq-discuss] DNSSEC on lookups of *.paypal.com no longer work
On Sat, May 14, 2016 at 08:55:58PM +0200, Uwe Schindler wrote: > > > Well, that's the smoking gun. Dnsmasq is doing the right thing, > > > and your upstream server at 212.202.215.1 is broken. I realise > > > that doesn't solve the problem, but at least you know where to > > > work now :) > > > > > > (the reason dnsmasq is returning SERVFAIL is that there's a > > > chain-of-trust from the root that says paypal.com is signed, > > > If the answer to the paypal.com query isn't signed, it may be > > > a false answer, so it can't be trusted.) > > > > Of course this is the right thing to do! > > > > I will contact the upstream provider and ask them to fix this! > > > > Interestingly, two of their three IPv4 DNS servers have the > > problem. The 3rd one and all three IPv6 DNS servers are working > > fine. This explains why it sometimes worked. > > > > Maybe a good idea is: If a DNSSEC query fails and DNSMASQ knows > > more servers, retry on others, too? > > What do you think about this proposal? Hmm. I think the story illustrates the importance of controlling your own upstream resolver, or at least of using one you know you can trust. I think there are two main reasons why signatures are broken: 1. Domain manager had an error in signing and/or keys (usually a software problem with signing) 2. DNS hijacking (not necessarily of malicious intent) Sometimes people get started validating DNSSEC and lose their will to be doing so after a SERVFAIL or two. Those folks are better off disabling validation. But you're not necessarily among them, it seems; you're just getting occasionally broken replies from the upstream server. The problem I have with your idea is that you don't really have an automated means to determine the problem upstream. You simply cannot rely on a broken upstream server if you're going to validate. So you fall back on 8.8.8.8 for any DNSSEC failure ... but wouldn't you be better off just using 8.8.8.8 and dumping the broken one? I've said before what I do ... I have *both* dnsmasq and named running; dnsmasq on port 53 and named on 127.0.0.1:1035. The named is doing recursion only. Yes, I'm hard core. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC on lookups of *.paypal.com no longer work
Hi Simon, > > Well, that's the smoking gun. Dnsmasq is doing the right thing, and your > > upstream server at 212.202.215.1 is broken. I realise that doesn't solve > > the problem, but at least you know where to work now :) > > > > > > (the reason dnsmasq is returning SERVFAIL is that there's a > > chain-of-trust from the root that says paypal.com is signed, If the > > answer to the paypal.com query isn't signed, it may be a false answer, > > so it can't be trusted.) > > Of course this is the right thing to do! > > I will contact the upstream provider and ask them to fix this! > > Interestingly, two of their three IPv4 DNS servers have the problem. The 3rd > one and all three IPv6 DNS servers are working fine. This explains why it > sometimes worked. > > Maybe a good idea is: If a DNSSEC query fails and DNSMASQ knows more > servers, retry on others, too? What do you think about this proposal? Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] ProxyDHCP mode is broken for serving ipxe.efi to UEFI pxe clents
I have included a patch below that makes essentially two modifications to get
PXE working with the UEFI firmware in VMware.
- It only appends the layer number to the file name on BIOS x86.
- It always redirects the client to port 4011. To do that, only the siaddr is
set and neither a boot file nor a PXE menu are included in the Offer sent upon
receiving the Discover. In reaction to the ACK it then sends an ACK which
includes either the single boot file name and server, or the PXE menu.
This patch works to the same degree as my patch did. VMware boots fine with a
single boot service, and the menu also works if you specify multiple, however
you have to blindly navigate the menu because it is not shown on screen.
Michael
--- a/src/rfc2131.c
+++ b/src/rfc2131.c
@@ -63,7 +63,7 @@ static void pxe_misc(struct dhcp_packet *mess, unsigned char
*end, unsigned char
static int prune_vendor_opts(struct dhcp_netid *netid);
static struct dhcp_opt *pxe_opts(int pxe_arch, struct dhcp_netid *netid,
struct in_addr local, time_t now);
struct dhcp_boot *find_boot(struct dhcp_netid *netid);
-static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct
dhcp_packet *mess, struct in_addr local, time_t now);
+static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct
dhcp_packet *mess, struct in_addr local, time_t now, int pxe);
size_t dhcp_reply(struct dhcp_context *context, char *iface_name, int
int_index,
size_t sz, time_t now, int unicast_dest, int *is_inform, int
pxe, struct in_addr fallback)
@@ -824,7 +824,10 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
else
mess->siaddr = context->local;
- snprintf((char *)mess->file, sizeof(mess->file), "%s.%d",
service->basename, layer);
+ if (pxearch == 0)
+ snprintf((char *)mess->file, sizeof(mess->file), "%s.%d",
service->basename, layer);
+ else
+ strncpy((char *)mess->file, service->basename,
sizeof(mess->file));
option_put(mess, end, OPTION_MESSAGE_TYPE, 1, DHCPACK);
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ,
htonl(context->local.s_addr));
pxe_misc(mess, end, uuid);
@@ -879,11 +882,10 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
clear_packet(mess, end);
- /* Only do workaround for replies to 4011 */
- if (!pxe)
- mess->siaddr = tmp->local;
- else
- workaround = pxe_uefi_workaround(pxearch, tagif_netid,
mess, tmp->local, now);
+ /* Redirect the client to port 4011 */
+ mess->siaddr = tmp->local;
+ /* Returns true if only one matching service is available. On
port 4011, it also inserts the boot file and server name. */
+ workaround = pxe_uefi_workaround(pxearch, tagif_netid, mess,
tmp->local, now, pxe);
if (!workaround && boot)
{
@@ -903,7 +905,7 @@ size_t dhcp_reply(struct dhcp_context *context, char
*iface_name, int int_index,
option_put(mess, end, OPTION_SERVER_IDENTIFIER, INADDRSZ,
htonl(tmp->local.s_addr));
pxe_misc(mess, end, uuid);
prune_vendor_opts(tagif_netid);
- if (!workaround)
+ if (pxe && !workaround)
do_encap_opts(pxe_opts(pxearch, tagif_netid, tmp->local,
now), OPTION_VENDOR_CLASS_OPT, DHOPT_VENDOR_MATCH, mess, end, 0);
log_packet("PXE", NULL, emac, emac_len, iface_name, ignore ?
"proxy-ignored" : "proxy", NULL, mess->xid);
@@ -1989,7 +1991,7 @@ static int prune_vendor_opts(struct dhcp_netid *netid)
and jamb the data direct into the DHCP file, siaddr and sname fields.
Note that in this case, we have to assume that layer zero would be requested
by the client PXE stack. */
-static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct
dhcp_packet *mess, struct in_addr local, time_t now)
+static int pxe_uefi_workaround(int pxe_arch, struct dhcp_netid *netid, struct
dhcp_packet *mess, struct in_addr local, time_t now, int pxe)
{
struct pxe_service *service, *found;
@@ -2009,6 +2011,9 @@ static int pxe_uefi_workaround(int pxe_arch, struct
dhcp_netid *netid, struct dh
if (!found)
return 0; /* No relevant menu items. */
+ if (!pxe)
+ return 1;
+
if (found->sname)
{
mess->siaddr = a_record_from_hosts(found->sname, now);
@@ -2024,7 +2029,10 @@ static int pxe_uefi_workaround(int pxe_arch, struct
dhcp_netid *netid, struct dh
inet_ntop(AF_INET, >siaddr, (char *)mess->sname, INET_ADDRSTRLEN);
}
- snprintf((char *)mess->file, sizeof(mess->file), "%s.0", found->basename);
+ if (pxe_arch == 0)
+ snprintf((char
